-
15. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
@Transactional(propagation=Propagation.REQUIRES_NEW) doesn't reopen a transaction, but creates a new one. In this case, if you modified any audited entities in the new transaction, you would get a new revision entity etc. All would work normally. It's just another transaction from the Envers point of view.
Adam
-
16. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Hi Adam,
Yes, I understand that. The question was meant to be in the context of using OpenSessionInViewFitler and having it pre-open a session or "warming" it up. -
17. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Unfortunately I have no idea what's OpenSessionInViewFitler so I won't help you much here . -
18. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Hi!
@Adam, OpenSessionInViewFilter links a new hibernate session to the actual thread when a request comes into a server context. When the request ends it close the session.
So if you have a transactional proxy inside a request it´s the same case as adam describes: new transaction, new revision.
The only issue I see here could be if you want to generate audit info at request level because the new transaction has its own commit.
@Sharath, What are you thinking the problem could be?
Hernan.
-
19. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Not a problem per se, but rather a question as to the behavior
If you use OSIVF (OpenSessionInViewFilter), it is a servlet filter working at the http session level. It was mentiond that this could be a solution to "defer" the flush when working with the springframework. The reason it would work is that the filter changes the flush mode to NEVER and forces Spring to leave the Session open in its beforeCompletion (that is really the point of the discussion right?). My understanding is that OSIVF defers the close so that when Enver's AuditSync's beforeCompletion happens, the session is not closed. Therefore this line of code would evaluate to false (ignoring the isManualFlushMode check which returns false when it is NEVER)
if (FlushMode.isManualFlushMode(session.getFlushMode()) || session.isClosed()) {
Now, when Propogation.REQUIRES_NEW is used, I would think that OSIVF is not in the picture, since the filter is much higher in the thread stack and lower elements have no idea about it. Do you know if that is a correct assumption? Or is Spring intelligent enough to propogate the flush mode to the new transaction/session?
I understand that this is not envers related, but to me, I would worry about session.isClosed check returning true when running in a new txn, when the filter caused it to return false. An inexperienced developer might not be aware of these variations and could be a source of hard to diagnose defects.
-
20. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
This whole line of discussion could be moot if it can be confirmed that the temporary session does infact participate in the overall txn that controls the commit, at which point, i am less concerned about the use of the temporary session.
-
21. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
And where the Session is closed? If it's in a TX synchronization, then the best solution would be simply to make sure that Envers's TX synchronization is registered before the one that closes the session. Unless the session is closed in the filter, and then the tx is commited?
I must check how Hibernate Search handles that, as there work is also done in a TX synchronization, and it also needs an open session to read the data I think.
Adam
-
22. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Weel, the Session.isClosed evaluation is in AuditSync. As for the Envers TX Sync registration, is that something I have control over at the application layer? -
23. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
But at what moment the session is closed?
Normally (or rather, everywhere where I used Envers: in EJB3s and Seam) the Session "lived" longer than the transaction, that is, when the TX was commited, the Session was still open.
Spring seems to do something different. The Session is closed before the TX commits, so it must happen at some place.To avoid Envers using a temporary Session, the Audit-data writing must happen before the Session is closed. I can see two solutions:
1) Manually "flush" Envers changes before the Session is closed (would require some code modifications)
2) If the Session is closed in a TX synchronization, make sure that the Envers TX synchronization is registered first.
Solution 2) would also require a code modification to do nicely, but it can also be done now. You "just" need to get a Configuration object, then the appropriate AuditConfiguration, then the current Session, and from that you can call AuditSyncManager.getFor(currentSession) which registers the synchronization .
Adam
-
24. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
Ok.. I think I'm lost now. This thread, originally started with a discussion on why the session is closed, which I stumbled into when I started seeing the problem myself. So, it remains then, that the original issue with Spring transaction management with Hibernate in a JTA env is closing the session in its beforeCompletion, and one workaound is the OpenSessionInFilter, which I believe to be problematic and does not solve the issue with propogation REQUIRES_NEW
----
To Quote Andrew DePue:
For whatever reason, Spring closes the session in its beforeCompletion... it makes at least one exception (there is a way to tell Spring to defer close, but that is used primarily for the OpenSessionInView pattern - besides, I don't think this is simple to enable when one is using Spring managed session with their DAO support). I'm not familiar enough with the way Spring and Hibernate interact with JTA to know why - though I did see a message by Juergen (a main Spring developer) on the Hibernate forums indicating that it is because of an issue with WebLogic's JTA (if I'm reading it right). I've copied the code from Spring's beforeCompletion method below. It almost looks like Spring might be assuming that Hibernate's JTA integration will defer close all on its own - but that isn't happening in my case.
I might experiment with modifying the Envers beforeCompletion to open a temporary Session if the main one is closed...---
So, I think the best thing will be to try and confirm that the session being closed and use of a temp session does not violate atomicity w.r.t to the txn. Hopefully I can confirm or deny that soon. However, I feel that Spring is very commonly used and if some discussion needs to be "opened" with the Spring team, it would be a fruitful discussion.
-
25. Re: Spring 2.0.6 + Hibernate 3.2.6 + Geronimo transaction ma
I was having this problem with Spring 2.5.6, Hibernate 3.3.2 and Envers 1.2.1 using JBoss's JTA.
I upgraded to Envers 1.2.2 and the problem has disappeared!