I have two questions :

Question 1)
In a 3-tiers application, and according to the caveat emptor sample ;
you bind a persistence context to each DAO

public abstract class GenericEJB3DAO<T,ID extends Serializable>
implements GenericDAO<T, ID> {

private Class<T> entityBeanType;

private EntityManager em;
...

Nevetheless in you book, for persistence context-per-conversation, the persistence context is bound to the SFSB

@Stateful
public class PlaceItemWithDAOsBean implements PlaceItem {

@PersistenceContext(
type = PersistenceContextType.EXTENDED,
properties =
@PersistenceProperty(
name="org.hibernate.flushMode",
value="MANUAL"
)
)
private EntityManager em;
...


-> to which class should be bound the persistence context?
-> same question if you want to mix session-per-request and session-per-conversation approach?


Question 2)
I understood that :
- in 2-tiers application, it's particularly appropriate to use the OSIV pattern or Thread-local pattern.
- in 3-tiers application, it is better (especially with EJB-CMT) to use JTA to bind the current persistence context to the current transaction.
Am-I correct?
In your comments of OSIV samples (caveat emptor), we can see that :
* With JTA you'd replace transaction demarcation with calls to the <tt>UserTransaction</tt> API.
* With CMT you would remove transaction demarcation code from this filter.
If the first comment target differences between Java SE and Java EE applications...
... when CMT could be used in a 2-tiers application? To my understanding 2-tiers application usually relies on simple POJO than EJB...

What about the use of the Thread local approach? You seems to mainly recommend it for a Java SE application?

Maybe the previous question is due to some confusion between different type of architecture you expose in chapters 11 and 16:
1) 2-tiers :
1.a) POJO (Session-Transaction management with Thread-Local)
1.b) POJO (Session-Transaction management with OSIV)
2) 3-tiers:
2.a) session EJB-BMT + DAO POJO (Session-Transaction management with Thread-Local)
2.b) session EJB-BMT-JTA + DAO POJO (Session bound to current JTA transaction)
2.c) session EJB-CMT-JTA + DAO POJO (Session bound to current JTA transaction)
2.b.1) session EJB-BMT + DAO EJB-BMT (Session-Transaction management with Thread-Local)
2.b.1) session EJB-BMT + DAO EJB-BMT-JTA (Session bound to current JTA transaction)
2.c) session EJB-CMT + DAO EJB-CMT (Session bound to current JTA transaction)

Is this list correct, complete?

Regards

Samuel

Can you summarize this in one or two coherent questions, please?

Question 1)
According to the caveat emptor sample (session-per-request);
you bind a persistence context to each stateless DAO:
->e.g. stateless DAO Generic EJB3DAO contains an EntityManager

In your book, for session-per-conversation, the persistence context is bound to the statefull conversation controller:
-> e.g. statefull conversation controller PlaceItemWithDAOsBean contains an EntityManager

=> What happens if your application wants to mix session-per-request and session-per-conversation patterns? To which class should be bound the persistence context ? To the stateless DAO? To the statefull conversation controler? To a statefull DAO (in this case the DAO become the conversation controller and has to be statefull even if it is not only used whithin a conversation)?


Samuel

Question 2)
In your javadoc of caveat emptor web filters, you wrote:
* With JTA you'd replace transaction demarcation with calls to the <tt>UserTransaction</tt> API.
* With CMT you would remove transaction demarcation code from this filter.

I do not understand the purpose of the second comment: when CMT could be used in a 2-tiers application?
To my understanding 2-tiers application usually relies on simple POJO instead of EJB (and it is what you've done for the caveat emptor application [native version], business objects and DAO are implemented as POJO and not as EJB).

Samuel

Question 3)
In chapter 11.1 you discribed 3 solutions to propagate the persistence context:
-> ThreadLocal
-> JTA
-> EJB-CMT

In chapter 16:
-> the caveat emptor application [native version] uses the OSIV pattern and none of the three previous strategies (or maybe the ThreadLocal strategy if the getCurrentSession() binds automaticallu the session to current Thread as the Hibernate doc seems to indicate).
-> the caveat emptor application [JPA version] uses the stateless EJB-CMT strategy.

=> It was then not clear for me to decide which one to use, for which kind of architecture (2-tiers, 3-tiers; with or without conversation).
Could you summarize this please: what is possible, what is recommended?

Samuel

You require a more powerful "binding", or persistence context handler. The way JBoss Seam does it is preferred for this situation, see the last chapter of the book or any Seam example that uses a Seam-managed persistence context.

1. This is not correct, the OSIV native version in chapter 16 relies on ThreadLocal binding. The servlet filter starts a transaction, which binds the "current Session" to a ThreadLocal, and it commits a transaction, which unbinds the "current Session" from the ThreadLocal and closes it after flushing.

2. JPA does not support persistence context propagation unless you use injection by an EJB3 container, usually you then also use EJB-CMT. (Although it is possible to use JTA transaction demarcation with EJBs.) You can not get any kind of EntityManager propagation with JPA, if you are not using EJBs.

3. This is all summarized in the book, you need to read these chapters again. Yes, I know it's quite complicated... my recommendation is to pick the environment you are going to work in and read what is supported there. If you can pick any environment, use JBoss Seam, which simplifies and unifies all that stuff.

What is the solution if a company does not want to move on JBoss Seam?

Yes you right about OSIV, I read maybe to quickly chapter 11.1.2 of your book ;-) but I get the right information on
http://www.hibernate.org/42.html where it is also clearly indicated that the getCurrentSession() binds the session to the current Thread.

What's is also the case with Hibernate 2.x because I remembered having implemeted ThreadLocal variables for the current Session and Transaction in the HibernateUtil class?

Samuel

You look at Seam and you duplicate what Seam is doing...