Dec 5th, 2005, 10:48 PM
Hibernate interceptor and threading
I have a need to execute some business logic whenever certain domain objects are inserted/updated. The problem is that the business logic is complex and requires several DAOs for read-only data access. Without duplicating logic, how can I utilize these DAOs from within the transaction scope of the interceptor?
I am using HibernateTransactionManager with transaction proxies around my business objects.
1) Does the HibernateTransactionManager support PROPOGATION_REQUIRES_NEW? Will this create another Session for use by the read-only DAOs?
2) Is the Session bound to the current thread? If so, can I execute this business logic in a separate thread? What would I have to do to ensure that this gets executed after the changes to the object have been committed?
In all cases, I want the changes to the object to be persisted to the database just prior to this logic being executed. So I need the following to happen:
1) The changes to the object are committed.
2) If the object was changed, it triggers the additional business logic.
3) The additional logic needs to load related objects, and perhaps the original object itself, so it must be able to see the changes.
4) The additional logic will need to persist changes to the related objects loaded in #3.
Dec 5th, 2005, 10:51 PM
I guess I should clarify. I DON'T need the additional business logic to execute within the transaction scope of the original action. I just need to make sure that the logic is triggered by the interceptor and that it can reuse my Spring-configured beans.
Dec 16th, 2005, 08:24 AM
OK, right now what I am doing is grabbing the changed objects in onFlushDirty and onSave and storing them in a HashSet. Then, in afterTransactionCompletion, I am executing my other DAOs on the objects in the HashSet. I found two problems.
First, I couldn't get the changes to persist. I'm guessing that, because the transaction had ended, the Session is in readOnly mode?
Second, I tried executing the DAO operations in a separate thread, hoping that this would cause a new Session to be created. At first, it seemed like this worked. However, I soon ran into an error where it looked like the changes from the original transaction had not yet been flushed to the database. I got an integrity constraint violation because one of the generated ID's did not yet exist in the FK table. What, then, does afterTransactionCompletion mean? I would figure that, at that point, I could open a new Session and see all the changes committed in the previous session. Am I way off?