Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Gnaniyar Zubair
Need Suggestion using JPA instead of Service Builder
February 6, 2013 12:09 PM
Answer

Gnaniyar Zubair

Rank: Liferay Master

Posts: 601

Join Date: December 19, 2007

Recent Posts

HI,

Liferay is generating the services to persist the data into database via JPA / Hibernate through Service Builder. But It doesn't support for foreign key, one-to-many, many-to-many,etc. So my client wants to handle the DAO layer directly through JPA with Eclipse Hyperlink or Hibernate without touching Service Builder.

Because of mentioned limitations in liferay's service builder, is it the best way to handle via JPA ? As per our requirement, we dont need to produce any webservices . At this situation, what is your suggestion whether we can go for JPA or Service Builder ?

Please throw some lights on this.

-Gnaniyar Zubair
David H Nebinger
RE: Need Suggestion using JPA instead of Service Builder
February 6, 2013 12:43 PM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6276

Join Date: September 1, 2006

Recent Posts

1. Use JNDI to lookup database connections. Define them using a connection pool.
2. Isolate out as a separate jar if multiple, separate plugins (wars) will be using them. Potentially deploy to global lib directory of container to facilitate reuse, but this incurs server restart to deploy update.

Your biggest issue will be runtime resource consumption and synchronization. With multiple separate WARs all using hibernate/jpa separately, you could end up w/ too many connections to the database. Also you'll need to disable the caching otherwise you'll face issues w/ possible stale data.

In the end, I'd recommend your clients stick with SB. Even though it is not perfect, it will not have these kinds of issues to deal with.

As far as their specific concerns:

1. Foreign Keys - SB will not generate sql scripts to create the FK constraints. But you don't need to allow SB to actually create the tables. We do not here; our DBAs create the tables with appropriate FK constraints and just use SB to create the access layer.

2. One to Many relationships - No, it's not really supported, but it's not much of a challenge either. SB will generate finders when you define one for the child entity that takes the parent key value. From a development standpoint, instead of a simple "parent.getChildren()" method on the parent object, you use a "ChildLocalServiceUtil.getChildren(parent.getId())" sort of thing.

3. Many to Many relationships - This certainly isn't handled by SB, but you can define the join table as an SB entity w/ appropriate finders to find the list for either side of the join.

The benefits of SB, though, are as follows:

1. Single access layer that is easily shared w/ all plugins. The code generated by SB operates in a single plugin, but can be shared across all portlets w/o worrying about extra database connections and/or code synchronization.

2. Single access layer allows for use of caching, since there is only one reader/writer stale data is not a concern.

3. Easily share the service jars w/ plugins w/o requiring container restart when updates are pushed.

4. SB generated code saves a huge amount of time during development. I will beat any developer generating a JPA/Hibernate layer hands-down due to the code that SB generates for me (we in fact have that competition going on right now, a separate servlet using hibernate takes significantly more time to implement changes than what it takes me to add to service.xml and rebuild the services).

Comparing the benefits to the missing pieces, personally I'd rather deal w/ the lack of support for O-2-M and M-2-M than I would dealing w/ a hibernate/jpa implementation, and I think if your clients understood the difference, they'd be onboard too...
Gnaniyar Zubair
RE: Need Suggestion using JPA instead of Service Builder
February 7, 2013 1:02 AM
Answer

Gnaniyar Zubair

Rank: Liferay Master

Posts: 601

Join Date: December 19, 2007

Recent Posts

David,

Thanks for detailed explanation about Service builder . Really it will be helpful to me to recommend service builder instead of JPA / Hibernate.

Liferay's Message Board shows that you are a Legend because of your forum counting. But really you are a Liferay Legend. emoticon

Thanks again for your valid information.

- Gnaniyar Zubair
Gnaniyar Zubair
RE: Need Suggestion using JPA instead of Service Builder
February 13, 2013 7:27 AM
Answer

Gnaniyar Zubair

Rank: Liferay Master

Posts: 601

Join Date: December 19, 2007

Recent Posts

David,

Sorry to disturb you and Thanks again for your detailed explanation . As you mentioned Servicebuilder doesn't support one-many and many-to many, so we can handle those relationship by our own methods. ok fine

But my client is afraid of some queries :

1. SB generates lot of auto generated classes. For example, if we have 10 entities in one service.xml, then Service Builder will generate more than 80 files in IMPLEMENTATION LAYER in

model-impl folders
and
service--> base, impl and persistence folders


Also in INTERFACE LAYER, more than 100 files in

Model , Service --> Messaging and Persistence folder
.

Maintaining and Bug tracking with all these auto generated classes is very complex .

But Using JPA, we can avoid all those files and can achieve same features with minimal classes.


2. Also I have 2 entities. BOOK and STUDENTS . I am storing studenId in BOOKS table.
By passing the studentId, I will get list of BOOKS. Then if i need to get the Students information, then i need to pass the studentId to STUDENTS table .In this scenario , Database is hitting two times one is for fetching books from BOOK table another hit is for receiving students from STUDENT table.
BookLocalServiceUtil & StudentLocalServiceUtil .

But in JPA , we can use mapping option to fetch the BOOK and STUDENTS details in one database hit.


3. If we generate big application with lot of services (entities) using SB, will it be any Memory leak?

As they have worked with some JPA applications previously, they are very confident with handling Transaction Management and DAO layers. But now they are planning to use SB if they are cleared with above queries. As this application may handle millions of organization and sub organization members accessing services, they need to design with suitable architecture. so would be great if you clarify above things.

- Gnaniyar Zubair
David H Nebinger
RE: Need Suggestion using JPA instead of Service Builder
February 13, 2013 9:35 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6276

Join Date: September 1, 2006

Recent Posts

Gnaniyar Zubair:
1. SB generates lot of auto generated classes. For example, if we have 10 entities in one service.xml, then Service Builder will generate more than 80 files. Maintaining and Bug tracking with all these auto generated classes is very complex.


You don't maintain or bug track generated code. The only files developers will edit are the service.xml file and the Xxx(Local)ServiceImpl classes. The rest of the code is boilerplate. Developers should not be making changes to them, so there's no maintenance or bug tracking the corresponds with them.

But Using JPA, we can avoid all those files and can achieve same features with minimal classes.


Even for JPA, it is still best practice to use a separate DAO per entity. With SB, you get one XxxLocalServiceImpl per entity (plus one if you've enabled remote services). Instead of having one pojo per entity, you've got an interface and a bunch of implementation classes. Big deal. You're not editing/maintaining that code, so it's not a concern.

2. In this scenario , Database is hitting two times one is for fetching books from BOOK table another hit is for receiving students from STUDENT table. But in JPA , we can use mapping option to fetch the BOOK and STUDENTS details in one database hit.


This is a known issue w/ Service Builder. Nothing I can do to help you there.

3. If we generate big application with lot of services (entities) using SB, will it be any Memory leak?


They're just extra classes. Why would anyone think that extra classes result in a memory leak?

SB is not an ORM, at least in the sense of what an ORM means today. SB is meant to solve specific problems in a portal environment, specifically that of separate plugins requiring data access to the same entities.

Imagine a system for an e-commerce site. One function is visible to users and they can submit orders. A second function is for the warehouse guys to update stock information. A third function is for managers to view the orders placed today.

In a classic servlet-based system, you would create a single web application that provided all of these functions. Here you would use JPA and the world is all puppies and flowers because, at the end of the day, you only have one reader/writer and any information cached by JPA is visible to all three functions.

In a portal-based system, however, you would create three separate portlets for the functions. And you'd probably create them as separate portlet plugins to ensure that coupling was kept to a minimum.

So you decide on the JPA route and build your JPA stuff. Since there's no easy way to share code among separate web apps, you copy your JPA stuff to each of the 3 portlets. You build them and deploy them, place them on the portal pages, and everything looks good.

Now, however, it is important to note that you have 3 separate database readers/writers, and information that they cache is not visible to the others. So user does a query to see what quantity of a widget you have in stock, and the number comes back as zero. Warehouse does an update and says there's now 10. User does a refresh, but since the information was already retrieved and is probably cached, they still see the quantity is zero. Management does a query and sees 2 orders, meanwhile 5 new users submit orders; management does a refresh and, since the data was already retrieved and cached, still only sees the 2 orders. Etc. So yes, here you would have your smaller class count and your single db call to retrieve an object graph, but the data being returned will likely be stale, so having those advantages really didn't help at all.

SB gets you back to a single reader/writer for multiple portlets. The three portlets in question would use the same SB service, and as each individual portlet is doing an update, there is no stale cache data that the other two need to worry about.

All that said, you can use JPA if you insist, but you have to be very specific when it comes to implementation:

1. Any plugin using the JPA framework must be in the same plugin. So from the 3 portlet example, these would all need to be in the same plugin project and deployed in a single war. This is the only way to mitigate the stale cached data issue, but the cost is the tight coupling of all of the plugins.
2. You won't be able to use the JPA stuff in a hook/ext, since you'd then be introducing the multiple reader/writer issues.

If I was forced to use JPA in a portal environment, I'd probably create a web service to wrap the JPA access and have the individual portlets invoke the web service. This would introduce more overhead in using JPA (for the marshalling and unmarshalling overhead of invoking a web service), but the portlets could all be separate plugins and it could also be used in a hook or ext plugin.
Muhammed Shakir
RE: Need Suggestion using JPA instead of Service Builder
February 13, 2013 11:25 PM
Answer

Muhammed Shakir

Rank: Junior Member

Posts: 33

Join Date: February 25, 2009

Recent Posts

I agree with David in toto. There is nothing that cannot be done with SB that you can directly do with JPA.

About the number of classes - If one is passionate about clean code and code that is resilient to changes, he/she will definitely use design principles and patterns to implement his services. And when you religiously design application around principles and patterns, you will anyways end up creating the number of classes that SB creates. Now the question is - Do you want to reinvent the wheel ?

Please explore FinderImpl, Custom Persistence Class concept etc. Moreover, using SB enforces patterns among all the programmers in the team including the trainee programmers. With SB everyone knows, where to write domain service, where to write use case service, where to write custom persistence, where to write custom finders etc.

If still the decision is to ignore SB then using JPA & Hibernate in Liferay will be as same as using it elsewhere. One benefit I see here is that you will be able to switch from one ORM to the other by modifying your DAO (Use Abstract Factory to design DAOs - see DAO J2EE design pattern) classes.

Hope this helps.
Gnaniyar Zubair
RE: Need Suggestion using JPA instead of Service Builder
February 14, 2013 12:56 AM
Answer

Gnaniyar Zubair

Rank: Liferay Master

Posts: 601

Join Date: December 19, 2007

Recent Posts

Thanks David and Shakir for sharing your thoughts and detailed explanation on this issue.