On my first attempts to use the HARDeployer, everything seemed to work except that no data actually got stored by my EJB. Went back to the doco (haven't used Hibernate before), ahhh, I have to pull the chain...

But hang on. Isn't it possible for org.jboss.hibernate.session.EjbInterceptor to check whether rollback has been set on the transaction, and if not set, invoke flush.

After all, section 9.7.1 of the hibernate reference document stipulates that "if you happen to be using the Transaction API you don't need to worry about this step".

One reason for using EJB is to have declarative transactions so I don't have to worry about managing them. The container is managing the transaction, so, the flush should be part of that perhaps ???

The interceptor should definitely take care of this, but ONLY if it is the bean that started the txn, and when the txn is about to commit.

Isn't it?

Just do a flush yourself in your code using the session.

Sure we can, but the point is, should we have to ?

I've got the same problem - session not flushed when transaction commits. I think session.flush() needs to be added into org.jboss.hibernate.session.TransactionSynch.beforeCompletion()

public void beforeCompletion() {
try {
session.flush();
} catch (HibernateException e) {
log.error("Could not flush session on end of transaction", e);
}
}

Besides this, there's one more problem here. It's all fine when only EjbInterceptor is configured in container-configuration (providing session.flush() is added).
But when I configure also servlet filter (exactly following Wiki instructions) it all get wrong. For example, when I deploy my ear with ejb & web modules:

1. Container deploys EJB module.
2004-08-16 13:48:59,543 DEBUG [org.jboss.hibernate.session.EjbInterceptor] Configuring EjbInterceptor [service=jboss.har:service=Hibernate, scope=transaction]

SessionContext.prepareSessionFactory("java:/hibernate/SessionFactory", Scope.TRANSACTION) called here.

2. Container installs servlet filter.
2004-08-16 14:02:42,418 DEBUG [org.jboss.hibernate.session.FilterInterceptor] Configuring FilterInterceptor [service=jboss.har:service=Hibernate, scope=thread]

SessionContext.prepareSessionFactory("java:/hibernate/SessionFactory", Scope.THREAD) called here which overrides scope for this jndiName in scopes Hashtable.

3. I call an ejb from my scheduled service (NOT from a servlet). In ejb I get a session: SessionContext.getSession("java:/hibernate/SessionFactory") and I given a session with scope THREAD and which is not enlisted in transaction! this is not correct behaviour for ejb.

We have actually been discussing a separate option on the interceptors dealing with flushing of the session. This along with a bunch of other enhancements will be available in the next version of the integration, which will be released with the next 3.2.6 release (which should be mid-September).

Just so everyone is aware, the enhancements will be:
1) Coupling between the interceptor/managed-session and the MBean;
2) Configuration options for flush();
3) Configuration options for auto transaction handling for session factories registered with "thread" scope;
4) Attachment of Hibernate Interceptor instances to the managed sessions or session factories.

Well of course! How can this be any different? Any suggestions (or fixes) most welcome...

And just as a clarification, the difference between thread and transaction scope is actually pretty trivial. It really just has to do with how the reference to the session is stored and associated to a context. In thread scope, a ThreadLocal is used; in transaction scope, a TransactionLocal is used. That has *absolutely no* bearing on whether a session participates in ongoing transactions or not.

Steve,

If I install both EjbInterceptor & Servlet filter there're two contexts and they should not interfere with each other. (I suppose interceptor configured with transaction scope and filter with thread scope).

In current implementation SessionContext.getSession needs to be passed both jndiName and scope to return correct context because it cannot guess from where it is called.
Session session = SessionContext.getSession("java:/hibernate/SessionFactory", Scope.TRANSACTION);
But when I explicity configured filter/interceptor for particular scope - why should I say it again?

I would suggest to bind correct session to JNDI in Interceptor/Filter. then just lookup session in bean/servlet
Session session = (Session) new InitialContext().lookup("java:comp/HibernateSession");
I've just sketchy implemented it and it seems to work fine. Just wondering if you like the approach?