1. Home
  2. Development
  3. RE: Using OSGI transaction manager

RE: Using OSGI transaction manager

thumbnail
Juan Gonzalez, modified 5 Years ago.
Using OSGI transaction manager
Liferay Legend Posts: 3089 Join Date: 10/28/08 Recent Posts
Hi! In order to use JPA, I am NOT using Service Builder. I am using OSGI Aries JPA.Together, I would like my portlets to be able to join the same transactions than Liferay's services.
Is there a way to use OSGI transaction Manager for both Liferay's services and custom portlets?
Thanks!
thumbnail
Christoph Rabel, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
While I can't help you, what you did is quite interesting.

I tried to use Aries & JPA about 2 years ago but got stuck somewhere with blueprint. I gave up at that time because the JPA/OSGI Aries thing felt quite fragile and "experimental".
Could you outline how you implemented it? Which libraries/versions did you use? Any special steps?
thumbnail
Juan Gonzalez, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 3089 Join Date: 10/28/08 Recent Posts
Christoph Rabel:

While I can't help you, what you did is quite interesting.

I tried to use Aries & JPA about 2 years ago but got stuck somewhere with blueprint. I gave up at that time because the JPA/OSGI Aries thing felt quite fragile and "experimental".
Could you outline how you implemented it? Which libraries/versions did you use? Any special steps?
My intention is to publish a blog with all needed steps. Although I spent some days with this, in the end doesn't seem too hard (hardest thing is to get documentation from Aries JPA!).
thumbnail
Christoph Rabel, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Ah, nice.
A colleague of mine spent some days with it too and the result was quite "murky". I tried it too, but didn't get as far as he did. Some dependencies blueprint or aries worked, but Liferay 7.0 DXP didn't start anymore. And we had other small issues too, in the end we decided to go with SB since we simply didn't trust it.
We currently use SB for small projects (couple of tables), for larger projects or where we would need to write a ton of custom sql, we create extra applications and usually just "bundle" them together with Liferay on a reverse proxy. For the frontend we use javascript applications.
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Hey, Juan!


Liferay's transaction management is based upon Spring but I think it is also exposed via OSGi, so it may be possible to get your hands on it, but I don't think it will feel as clean as a regular AOP-based transaction wrapper.

Out of curiosity, are you concerned about the bleed of the JPA dependencies across your module landscape?  Since JPA-based entities are annotation based, it really means that any consumer of the entities will also incur the dependencies and pretty soon the landscape turns into a tightly coupled mess, or at least that's how it keeps working out for me. I'm wondering if you've found a way to not incur those penalties?

And, note to all of those googlers that end up here wanting to know how to use JPA in Liferay instead of SB, just don't do it. SB is seen as an old fashioned and incomplete ORM (since it doesn't handle the parent/child relationship cascade handling, etc), but it is designed to work in an OSGi environment without bleeding dependencies everywhere while also supporting automatic caching (EhCache) to reduce DB hits, automatic indexing in Elastic (for optimized search capabilities), integration with Liferay frameworks for workflow handling, asset handling, fine-grained resource permissions, local and remote (/api/jsonws for AJAX-based goodness), etc. JPA and Hibernate are not going to bring all of these facilities in for you, so choosing JPA means you're choosing to implement all of this stuff on your own.

I happen to know Juan and know that he has a lot of Liferay experience and knowledge and if he is choosing this path, he has seriously considered all of these things before just jumping on JPA.

But if you end up on this thread because you just want to use JPA but haven't considered all of the ramifications, I encourage you to turn around now and go back to SB...
thumbnail
Juan Gonzalez, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 3089 Join Date: 10/28/08 Recent Posts
Hi David, thanks for answering.

Can you elaborate on that "dependency hell" you're talking about in your case?

Yes, I am aware of all of those things you aren't getting when not using Service Builder. In fact, I am not sure about the decision. There is a chance that my current project will be migrated to one of my ex-employer great tools -> Quarkus, so there JPA is more "native".

There are some things that I don't like how are created (those UUID for assets masked as index although can be a PK, one-to-many not reflected as DB foreign keys...). That's why I was exploring the path of doing these features without Service Builder. For those cases I need a common transaction manager, and I can't see how to do that properly.

Maybe I just should change DB by using upgrade processes and use all of those "automagical" code

I will try to publish a blog post about how to add JPA into Liferay.
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Using OSGI transaction manager
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Well, what I was running into, since the POJOs are decorated with JPA annotations, any consumer module then takes on the JPA dependencies...

In general I follow the pattern of creating a separate API and Impl modules, just so I can encapsulate the dependencies in the Impl module and the consumers can just use the API w/o incurring additional dependencies.

But with JPA, your POJOs are annotated with JPA annotations and they are typically also your DTO objects... So they would go in the API module, but that means consumers of the API also inherit the JPA dependencies because of the annotations.

For the other concerns... UUID is only needed if your entity is asset-framework-enabled; if you don't need asset framework support, just disable the UUID in the <entity /> tag.

Foreign keys, ugh, yeah I too like foreign keys because having the referential integrity in your database I think is a good thing. I get that Liferay doesn't use them because it truly does simplify handling of upgrades, table changes, dirty deletes, but I would never advocate for not using them in your custom entities.  Adding FKeys via an upgrade process can be a great way to apply them too, plus you can still use SB for them as SB won't care if there are FKey definitions or not. It's just not going to manage them for you emoticon