[jira] [Updated] (TAP5-2159) @AfterCommit and Nested behavior

["Martin Kersten (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kersten updated TAP5-2159:
---------------------------------

    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. :)

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

(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 commits. Am I right here?

There is the PersitenceContext annotation and that somehow I can use it to control transactional behavior but In my oppinion 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 didnt found anything about it. Maybe I am blind. :)

        Summary: @AfterCommit and Nested behavior  (was: @AfterCommit and Nested Transactions)
    
> @AfterCommit and Nested behavior
> --------------------------------
>
>                 Key: TAP5-2159
>                 URL: https://issues.apache.org/jira/browse/TAP5-2159
>             Project: Tapestry 5
>          Issue Type: Bug
>            Reporter: Martin Kersten
>            Priority: Critical
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> 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. :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira