Fallacy 2: EJBs are too complex, POJOs are easier.

I had once a interesting discussion with a Java-developer, who hated EJBs and prefered POJOs in web container. I had to review his architecture and asked him about his solution:

I: How do you solved the transactionality?
Developer: Well, it was very easy. I only implemented a ThreadLocal. I open the transaction in my servlet and store the connection in ThreadLocal. My DAOs take the connection from the ThreadLocal and use it.
I: Cool. How long it took to implement the solution?
Developer:  Only 2 days with testing and doc.
I: O.k. Do you have some monitoring requirements?
Developer: Yes we have. I implemented a simple solution with Dynamic Proxy and a factory. I'm able now to monitor the methods. I combined the decorator with Log4J -> and it works well. I spent only one day for the implementation.
I: You need persistence?
Developer: Yes. But I do not like CMP 2.0. Also Hibernate was too complicated. I implemented my own lightweight DAO-solution. I map database records to VOs using reflection. Is much easier, than OR-stuff. I spent only 2 days implementing the whole framework. It is very easy.
I: Is it transactional?
Developer: Of course.
I: What happens if you request 2 times the same object in the same transaction?
Developer: You will get two instances!!
I: So it is not transactional. You should be careful. The whole stuff can become inconsistent...
Developer: Really? No Problem. I can also implement a transactional first level cache - it is only a Map...

[...]

We discussed also other issues, like threading, scalability constraints, real time monitoring etc. He provided or implemented for every needed aspect an own solution. I approved finally his design, because it was clean and the developer really experienced. But: the code is clean but not maintainable! Many Java developers do not know what e.g. ThreadLocal is and how it works.

It is nothing special in this conversation. If you consider only the development phase, EJBs seem to be too complicated. If you consider also the non functional  stuff, it becomes more interesting. Only few developers care about real time monitoring (JSR-77), threading, proper load balancing etc. If you are using POJOs in production you will only see your servlet and you will not know what your application is doing. So EJBs remain complex, but the complexity has its roots not in the EJB spec, but in the fact, that we are mostly developing distributed and transactional applications.

EJB 2.1 were not elegant, there were some design flaws (e.g. the method getPrimaryKey in EJBContext, can be only invoked in case you are in an CMP 2.0), you had to remember some rules (e.g. remote methods had to throw RemoteExceptions etc.), but it was not complicated. Experienced Java-Developers were able to deploy a CRUD J2EE 1.4 applications in about 0,5 hour (Ant+Xdoclet).

EJB 3.0 are really great. But also not easy. Just see my entry "Nothing Is Transparent".

Both specs J2EE 1.4 and Java EE 5 are o.k., but Java EE 5 is nicer and cleaner... 

Comments:

You seem to be very worried about "transactionality", yet I am not sure you and your firend always talk about transactionality when using that word.

Storing a connection in a threadlocal has little to do with transactionality. Transactionality is about defining a scope for a set of data transformations, and rollbacks handling. Using threadlocal is more about connection and concurrency management than anything else.

Requesting twice the same object and having 2 different instances in a same transaction is not necessarily breaking transactionality. It is inefficient and error prone, but the link with transactionality is blur to me.

Posted by chasethedevil on August 03, 2006 at 06:13 PM CEST #

I'm not very worried about "transactionality". I even happy about this (I had some contracts in the past to solve the problems):-).

"Storing a connection in a threadlocal has little to do with transactionality."

It has. If you use JDBC, the transaction is bound to the connection. If you would like to execute every facade or business delegate method in a transaction, ThreadLocal is a workaround for this.

Having a simple EJB in the front of your component, you do not have to care about this stuff. It simply opens the transaction. Everything which is executed in synchronous way participates in that transaction.

"Requesting twice the same object and having 2 different instances in a same transaction is not necessarily breaking transactionality."

It is. In a transaction you expect always the same view to the same data. Having different copies of one object breaks this rule. Your data even in a transaction becomes inconsistent.

From the overall point of view, it is transactional, but from developer point of view is not...

Posted by Adam Bien on August 03, 2006 at 08:43 PM CEST #

"Having a simple EJB in the front of your component, you do not have to care about this stuff."

Same with Spring. No EJB's required. Sbring handles it for you.

"Requesting twice the same object and having 2 different instances in a same transaction is not necessarily breaking transactionality."

This is Correct. If the data is identical in both instances, it isn't breaking transactionality. You must be assuming that everyone uses Hibernate or EJB. This isn't the case. There are plenty of other alternatives that work fine and don't break transactionality even though they wouldn't necessarily return the exact same instance of an object.

Posted by john smith on August 04, 2006 at 07:20 AM CEST #

John,

just consider the database. If you are in a transaction and execute a query, you will get every time the same result. If you change the state of the database in the same transaction you will SEE your changes. Some persistence framework do not provide this quality. This means: lost updates in a transaction can occur.

Spring, CORBA, .NET or home grown frameworks provide the transactionality.

What I would like to point out: either you are using Java EE, or you have to find an alternative. Reinventing Java EE with JDBC isn't necessarily easier, than Java EE.

I will discuss the transactionality in a new post.

Thank you for your comment!

Posted by Adam Bien on August 04, 2006 at 11:31 AM CEST #

You could consider Spring Framework to solve typical EJB problems like transactionality
http://www.springframework.com
http://bloggingg.blogspot.com

Posted by David on August 06, 2006 at 04:54 PM CEST #

David,

of course. But Spring alone isn't a solution. You would need also something like Hibernate. So you need either Java EE or Spring. The choice depends only on your specific needs

Posted by Adam Bien on August 06, 2006 at 08:13 PM CEST #

>
I: What happens if you request 2 times the same object in the same transaction?
Developer: You will get two instances!!
I: So it is not transactional. You should be careful. The whole stuff can become inconsistent...
<
In this regard I think you need to be careful. Transaction Isolation levels come into play and the need for a 'Persistence Context' is an ORM specific requirement and not necessary for more traditional JDBC access.

Posted by Rob Bygrave on December 16, 2006 at 02:20 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License