[TAP5-2159] @AfterCommit and Nested behavior

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Won't Fix
• Assignee: Unassigned
• Reporter: Martin Kersten
• Created: 23/Aug/13 08:08
• Updated: 09/Sep/13 23:19
• Resolved: 09/Sep/13 23:19

Description

It seams that @AfterCommit does not value 'nested' behaviour. This would introduce awefull runtime problems in data consistency if used that way. I reviewed some code lately and found places where this transactional behaviour has to be considered a critical bug in this application. Can you please confirm, that these assumptions are right or wrong and also provide a better way to handle transactional behaviour?

(from emaillist)

The problem I have seams within the documentation. For @CommitAfter the documentation states that the transaction is committed at the end of the method.

Therefore I think that for the case:
@CommitAfter
a()

{...}

@CommitAfter
b()

{ a(); }

At least two commits will happen for each of those methods. Am I right here?

There is the PersistanceContext annotation and that somehow I can use it to control transactional behaviour but In my opinion this focus about using a second session for two different persistent contexts. Am I right on this one?

So in the end it looks like programming or using some other sort of mechanism that is aware of nested logical transactions and ignores the commit inside an ongoing transaction. This behavior can be introduced using HibernateSessionManager.

There is also this post http://tawus.wordpress.com/2011/04/23/tapestry-magic-5-advising-services/ which describes exactly what I need.

The question here is there anything shipped with tapestry that allows this kind of behavior or am I missunderstanding @CommitAfter and this behavior is already present?

Is there a standard way to control whether there is a ReadOnly transaction going on or not? I did not found anything about it. Maybe I am blind.