EntityHome is written to be used as a JavaBean* which is why it has the @transactional annotations. I believe these will be ignored if your bean is an EJB as transaction management will be deferred to the EJB container.
Everything being saved to the database is because the EJB persistence context lacks the ability to set the flush mode to manual unlike the Seam PC.
Is there any particular reason not to use the Seam PC? It really does save a lot of trouble and give you a lot of features (just look s:convertEntity for one). If you use the Seam PC this takes away a lot of the headaches and gives you the flush=manual capabilities also
* I say this because to use EntityHome as an EJB means you have to subclass it and write your own local interface. Under EJB 3.1 though this should be resolved since interfaces are not required?
Thank you Andy for explanation. Agree - seems that
EntityHome is more suitable for POJOs, so I decided
to avoid it with EJBs for consistency reason. I'm curious
why ejb spec doesn't include one obviuos thing -
which eliminates such side effect. So, and here I switched to
Just one question, may be not related to the subject - Is it a
common approach to use
for ejb methods, that do not perform updates, but only queries ?
Running query without transaction should be faster, and even in case if exception is raised during query execution - the
outer transaction (if any) will be rolled back.
But I'm in doubt - for example s:convertEntity,
EntytyHome.getInstance() both require active transaction for
some reason. Why ?
I'm curious why ejb spec doesn't include one obvious thing -
The whole flushMode=manual is apparently fairly controversial. You will see a number of places where people (Gavin, Pete, the authors of the EJB 3.0 book I was reading this week oddly enough) all lament the fact that the idea of flush=manual was rejected. Take a look at section 8.3.3 of the Seam manual for Gavin's take :
As the result of a truly stupid and shortsighted decision by certain non-JBoss, non-Sun and non-Sybase
members of the EJB 3.0 expert group, there is currently no simple, usable and portable way to implement atomic
conversations using EJB 3.0 persistence.
As for transactions on query only methods, it is my understanding that all queries run in a transaction, either an implicit one, or explicit.