[
https://issues.apache.org/jira/browse/TAP5-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kersten updated TAP5-2159:
---------------------------------
Remaining Estimate: 4h
Original Estimate: 4h
> @AfterCommit and Nested Transactions
> ------------------------------------
>
> 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 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. :)
--
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
