I'm trying to like the specification, but I just can't.
Here's one more reason why:
I have SSB (Stateless Session Beans). The persistence is via JPA (implementation is Hibernate).
All my business method look something like:
public Object1 doSomething( Object2 ) throws ApplicationException1;
I use CMT (Container Managed Transactions) which means that the container calls begin() before the method call and commit() after the method call is over.
The problem: what happens if the transaction is rolled back?
A RollbackException is thrown. It looks common sense to try to rewrite it as ApplicationException1. Well.... YOU CAN'T.
No F way (at least not an easy one).
Make the Beans stateful and use SessionSynchronization. UGLY - I don't want to be stateful.
Implement TransactionSynchronizationRegistry - just look at it.
Make a facade EJB that calls my own EJBs which should use requiresNew. One more level of abstraction? I have to change the contract? I don't have just one Bean, so a wrapper for every single one of them?
Switch back to BMT (Bean Managed Transactions) and call begin() and commit() myself. Well then the container becomes useless. But my business methods are rarely longer than a few lines, so I'm choosing this one.
CMT without any simple way to plug after commit() and this is an enterprise level spec? Really?
I'd be really happy if someone corrects me and shows me a simple way to do what I need.
2 thoughts on “EJB Sucks: one more reason why”
Hello everyone. The best way out is always through.
I am from Colombia and also now teach English, tell me right I wrote the following sentence: "The other usage of a house hail coverage crowd is that it offers soft cities to require the policy in their licenses into company, directly in the auto of a future price, insurance auto."
Regards 🙁 New york auto insurance quote.
Agreed, and so am i, waiting to be "debunked"... actually, i know why EJB is so popular: someone above the programmer likes it... that is the only reason that's needed...