I finally have an opportunity to use Hibernate in a heavy way after doing a brief cursory look at it a couple of years. I'm planning on using it in a product that makes it easy to setup an Intranet, a portal/CMS/Workflow type of thing with a bunch of other modules specific to Intranets. As part of this product, I want to include a public API so it can be extended by customers, consultants, etc.

I basically have adopted a strategy of hiding the underlying implementation of Hibernate through the use of interfaces. Thus there might be an interface called security.User which is actually implemented by a Hibernate persisted object called security.impl.UserImpl. A SecurityManager object would then dish out individual or lists of User objects. I've prototyped this out a bit and am quite happy with the results. However, I'm struggling a bit with how to handle the update of information.

It seems to me you have two choices. First you can adopt a declarative approach so that when you dish objects out and the user must call an appropriate save or update method in the SecurityManager. This would mean severing the object from the Hibernate session when you dish it out and using saveorUpdate to save it back. The other approach is to go the seamless style where changes made to the objects are automatically saved and as this is more in-line with the Hibernate/EJB approach it's what I would prefer to do.

Now having said that, I don't want the users of the API to have to call flush() or deal with the Hibernate session at all. No problem if your not using transactions, calling the close() method on the SecurityManager automatically flushes. The question (finally!) though is what to do about transactions? Ideally the user would be able to initate a transaction in the JTA and any Hibernate activity in that thread would be automatically enlisted. Is there any way to achieve this by specifying a Hibernate TransactionManager in the app server configuration?

If that is not possible, any other good suggestions? I was thinking of having a begin, commit and rollback methods on the SecurityManager and just do hibernate transactions within that, the hibernate transaction will automatically be enlisted in the JTA, though the user would have to call my commit or rollback method in addition to the JTA one, certainly not as elegant.

Thanks in advance for any and all advice.

Gerald

In Hibernate 2.1, Hibernate is aware of the TransactionManager, even if you are not using the Transaction API.

Note that if you are not using process-level cache, you don't actually need for Hibernate to be aware of the TransactionManager at all!

Just to be clear, if I have code similar to this below:

UserTransaction ut = context.getUserTransaction();
try{
ut.begin();
User user = SecurityManager.getUser("gnunn");
user.setPassword("password");
Site site = SecurityManager.getUserSite(user);
site.setName("main");
ut.commit();
} catch{
ut.rollback();
}

where the User and Site classes are actually dished out from a Hibernate session in SecurityManager, the code above will work correctly? My concern was that without an explicit flush, the code above might be in-determinate since Hibernate may issue the SQL to persist the objects before or after the transaction was committed/rolledback. Are you saying in 2.1 Hibernate automatically recognizes a JTA transaction is in progress and synchronizes on commit using something like a Synchronizer?

Thanks,

Gerald

P.S. Good to see your support is still the best, you really should start charging for it at some point like the JBoss Group.

Oh sorry, no, you still need the explicit flush().

I think we will make the JCA adaptor do the implicit-flush thing, like you suggest.

Thanks, I'll add transaction support to my over-arching context for now and that can dish out a Hibernate transaction object. Once your support for implict flushing is added it should be trivial to switch back to the JTA. The whole idea is to allow non-hibernate aware developers to work with the product API using the standard mechanisms they are used to.

Thanks again for the help,

Gerald

<br>

I'm just curious if this has been done?
I beleive not so, is it not an issue at all any more?

Best regards,
Jan Gifvars