Extended Persistence Context without EntityManager

[dan.j.allen]

This may be a silly question, but bare with me. Is it possible to have an extended persistence context without using an EntityManager (rather a native Hibernate Session)? By that, I mean that you can retrieve an object, render the view, and on postback, the following will still be true, because the previous Session is restored.

conversationScopedObject == session.get(conversationScopedObject.getId());

The reason I ask is because I am trying to get an understanding of what Seam/EJB 3 provides that Seam/Hibernate does not. I want to avoid using a detached object to do basic CRUD, and to do so I would imagine that the best way is to use the extended persistence context (otherwise known as session-per-conversation pattern). I don't want to go hacking up a solution. I am interested to know if this is something that is supported by Seam without EJB 3. If it isn't, then I will understand why EJB 3 is necessary.

[christian.bauer]

It's possible because Hibernate _implements_ the EJB 3.0/Java Persistence standard. So by definition it has to offer a superset of features. EJB 3.0/Java Persistence is needed because it is an industry standard of a subset of Hibernate features.

If you are looking for things that Hibernate can not do but that Java Persistence can not do, you will not find any. But it's also not useful to compare a product with a specification, compare product with product.

Seam offers easy access to the Hibernate feature superset (in addition to making EJB 3.0 standard features easier available). Read up on the Seam managed persistence contexts in the doc, you can use either EntityManager or Hibernate Session API with that.

[christian.bauer]

"If you are looking for things that Hibernate can not do but that Java Persistence can not do"

should be

"If you are looking for things that Hibernate can not do but that Java Persistence can do"

[pmuir]

What Seam offers over hibernate/ejb3 is a conversation scoped entitymanager/hibernate session, which (imo) is more useful than an extended persistence context. I never use @PersistenceContext, but always use @In EntityManager entityManager - EJB3 offers other stuff though (e.g. MDBs).

[dan.j.allen]

Hmm, what you said makes perfect sense, though I feel that I did not do a good job of stating my question. As a proud owner of JPwH I can positively say that I understand that Hibernate is a provider of the JPA standard (and a very good one!)

Let me try to be a bit more clear. I want to put my Hibernate session factory (or Session?) in the conversation scope so that it reattaches to the JDBC data source on a new request, but still uses the same first-level session cache. However, I would like to be able to do so without the EJB-microcontainer. It appears that Seam must rely on the microcontainer to use the extended persistence context, and when it does so, it always appears to inject it using the EntityManager as a target.

Perhaps this pseudo-code would be more clear. I want to be able to do:

@PersistenceContext(type=EXTENDED)
Session session;

Is something like this possible? Or would it be more like the configuration below?

<core:managed-hibernate-session name="extendedSession" scope="conversation" />

Basically, if there were anyway that the Seam developers could provide an example of a long running conversation that avoids the use of detacted objects using ONLY hibernate sessions, we would do backflips for you.

[christian.bauer]

This is all explained in the reference documentation, you can use JSF + Seam + Hibernate and nothing else. Check out /examples/hibernate in the Seam distribution.

[dan.j.allen]

Okay, I'm the ass. Sorry for wasting your time. Chapter 8.3 describes this very clearly with the Seam-managed SessionFactory and FlushMode feature of Hibernate. I also didn't read close enough (or slow enough) to realize that the session-factory-jndi-name attribute is actually the name of the session factory in the hibernate.cfg.xml file. Intuition wanted to mess with my head.

For those of you just joining us, turn your attention to this quote from the reference manual:

Seam lets you specify FlushModeType.MANUAL when beginning a conversation. ...changes will not be flushed to the database until we explicitly force the flush to occur.

and this code

components.xml

<core:hibernate-session-factory name="hibernateSessionFactory"/>
<core:managed-hibernate-session name="hibernateSession" auto-create="true" session-factory-jndi-name="WhateverYouLike"/>

hibernate.cfg.xml

<session-factory name="WhateverYouLike">
 <!-- props -->
</session-factory>

So what this is saying is that Seam can manage your hibernate sessions by using a Seam-managed Hibernate SessionFactory. If you inject that Session into a conversation-scoped Seam component, you now have a session-per-conversation for free! Using FlushMode.MANUAL you can even choose to delay the flushing of the session to the database across many different transactions.

Now, the challenge is for me to get this working in my little sandbox.