You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by sodium <so...@yahoo.com> on 2009/05/26 05:46:30 UTC
@CommitAfter rollback propagation
A quick question about tapestry-hibernate rollback propagation. As far as i
know, any function annotated with @CommitAfter will create a new transaction
similar to EJB required_new. But how would the nested functions behave?
For eg.
@CommitAfter
public void functionA() {
functionB();
}
@CommitAfter
public void functionB() {}
If functionB failed to commit:
1) Will functionA be rollback?
2) Or will functionA be commited under another new transaction regardless of
functionB?
--
View this message in context: http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23716428.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 30 May 2009 18:17:46 -0300, Juan E. Maya <ma...@gmail.com>
escreveu:
> I was thinking about something similar to what spring has to offer.
Me too. :) But using EJB3 annotations (are they part of a standard), not
the Spring ones, of course. I guess the step after this one would be to
build some security and access control support (a little like Spring
Security/Acegi).
> So yes, i think it should be in Tapestry IoC. Personally, one of the
> only things i miss from Spring is its transactional support.
That's the only thing I miss from Spring. The only reason I use it instead
of using Tapestry IoC, which I love. :) Howard did an awesome job of
picking the best features of Guice and Spring and improving them.
I guess we think almost the same about these issues. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by "Juan E. Maya" <ma...@gmail.com>.
I was thinking about something similar to what spring has to offer. So yes,
i think it should be in Tapestry IoC. Personally, one of the only things i
miss from Spring is its transactional support.
On Sat, May 30, 2009 at 10:07 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Sat, 30 May 2009 11:02:52 -0300, Juan E. Maya <ma...@gmail.com>
> escreveu:
>
> This sounds awesome Thiago. I could give u a hand if you want.
>>
>
> Nice to know I'm not the only one wanting transaction support in Tapestry.
> :)
>
> However, i still think that such library should be part of the core
>> framework.
>>
>
> Tapestry, the Web framework? If Tapestry-IoC has transaction management
> support, Tapestry the web framework has it indirectly. Of course, we could
> add support for annotations in page/component/mixin methods, but I think it
> is not a good idea (transactions don't belong in the vision layer).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: @CommitAfter rollback propagation
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 30 May 2009 11:02:52 -0300, Juan E. Maya <ma...@gmail.com>
escreveu:
> This sounds awesome Thiago. I could give u a hand if you want.
Nice to know I'm not the only one wanting transaction support in Tapestry.
:)
> However, i still think that such library should be part of the core
> framework.
Tapestry, the Web framework? If Tapestry-IoC has transaction management
support, Tapestry the web framework has it indirectly. Of course, we could
add support for annotations in page/component/mixin methods, but I think
it is not a good idea (transactions don't belong in the vision layer).
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by "Juan E. Maya" <ma...@gmail.com>.
This sounds awesome Thiago. I could give u a hand if you want.
However, i still think that such library should be part of the core
framework.
On Fri, May 29, 2009 at 2:27 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Fri, May 29, 2009 at 6:12 AM, Juan E. Maya <ma...@gmail.com> wrote:
> > hmm so @CommitAfter works as REQUIRES_NEW. A new transaction is created
> for
> > each method.
> > It would be great if the core support for hibernate would add more
> > transactional support. Maybe for 5.2? :) Does anybody know if there are
> > plans for something like this?
>
> I'm planning to write a generic transaction manager built on
> Tapestry-IoC and using annotations from EJB 3.x, but I don't have any
> start date yet, unfortunately. I don't think we should add more
> detailed transaction management that is specific to only one framework
> (Hibernate). We should focus on a generic transaction manager and them
> add their specific implementations (Hibernate, JPA, Cayenne, JTA,
> etc).
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: @CommitAfter rollback propagation
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, May 29, 2009 at 6:12 AM, Juan E. Maya <ma...@gmail.com> wrote:
> hmm so @CommitAfter works as REQUIRES_NEW. A new transaction is created for
> each method.
> It would be great if the core support for hibernate would add more
> transactional support. Maybe for 5.2? :) Does anybody know if there are
> plans for something like this?
I'm planning to write a generic transaction manager built on
Tapestry-IoC and using annotations from EJB 3.x, but I don't have any
start date yet, unfortunately. I don't think we should add more
detailed transaction management that is specific to only one framework
(Hibernate). We should focus on a generic transaction manager and them
add their specific implementations (Hibernate, JPA, Cayenne, JTA,
etc).
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by "Juan E. Maya" <ma...@gmail.com>.
hmm so @CommitAfter works as REQUIRES_NEW. A new transaction is created for
each method.
It would be great if the core support for hibernate would add more
transactional support. Maybe for 5.2? :) Does anybody know if there are
plans for something like this?
On Thu, May 28, 2009 at 8:04 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Not quite.
> The commit happens immediately after function exit, and it commit the
> current transaction, subsequent actions will then be performed in a new
> transaction, as detailed by Igor.
> So, the flow for your scenario is (assuming you haven't committed the
> current transaction (t1) before calling function A):
>
> call function A (t1)
> call function B (t1)
> end function B (t1)
> commit current transaction (t1), replace current with a new transaction
> (t2)
> end function A (t2)
> commit current transaction (t2), replace with a new transaction (t3)
>
> Remainder of request happens with transaction t3.
>
> HTH,
>
> Robert
>
>
> On May 26, 2009, at 5/262:42 AM , sodium wrote:
>
>
>> Thanks Igor,
>>
>> I think i understand it now. Basically every function which is annotated
>> with @CommitAfter will be commited at the end of the request when session
>> is
>> detached. I guess the only way is to group together whatever i wanted to
>> achieve into a single function and have it @CommitAfter.
>>
>>
>> Igor Drobiazko wrote:
>>
>>>
>>> @CommitAfter commits the transaction of the request. The transaction is
>>> created when the session is attached to the request. When functionB() is
>>> called the transaction will be committed and a new one will be created.
>>> So
>>> functionA() will commit the later transaction.
>>>
>>> On Tue, May 26, 2009 at 5:46 AM, sodium <so...@yahoo.com> wrote:
>>>
>>>
>>>> A quick question about tapestry-hibernate rollback propagation. As far
>>>> as
>>>> i
>>>> know, any function annotated with @CommitAfter will create a new
>>>> transaction
>>>> similar to EJB required_new. But how would the nested functions behave?
>>>>
>>>> For eg.
>>>>
>>>> @CommitAfter
>>>> public void functionA() {
>>>> functionB();
>>>> }
>>>>
>>>> @CommitAfter
>>>> public void functionB() {}
>>>>
>>>>
>>>> If functionB failed to commit:
>>>> 1) Will functionA be rollback?
>>>> 2) Or will functionA be commited under another new transaction
>>>> regardless
>>>> of
>>>> functionB?
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23716428.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Igor Drobiazko
>>>
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23718188.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: @CommitAfter rollback propagation
Posted by Robert Zeigler <ro...@scazdl.org>.
Not quite.
The commit happens immediately after function exit, and it commit the
current transaction, subsequent actions will then be performed in a
new transaction, as detailed by Igor.
So, the flow for your scenario is (assuming you haven't committed the
current transaction (t1) before calling function A):
call function A (t1)
call function B (t1)
end function B (t1)
commit current transaction (t1), replace current with a new
transaction (t2)
end function A (t2)
commit current transaction (t2), replace with a new transaction (t3)
Remainder of request happens with transaction t3.
HTH,
Robert
On May 26, 2009, at 5/262:42 AM , sodium wrote:
>
> Thanks Igor,
>
> I think i understand it now. Basically every function which is
> annotated
> with @CommitAfter will be commited at the end of the request when
> session is
> detached. I guess the only way is to group together whatever i
> wanted to
> achieve into a single function and have it @CommitAfter.
>
>
> Igor Drobiazko wrote:
>>
>> @CommitAfter commits the transaction of the request. The
>> transaction is
>> created when the session is attached to the request. When
>> functionB() is
>> called the transaction will be committed and a new one will be
>> created. So
>> functionA() will commit the later transaction.
>>
>> On Tue, May 26, 2009 at 5:46 AM, sodium <so...@yahoo.com> wrote:
>>
>>>
>>> A quick question about tapestry-hibernate rollback propagation. As
>>> far as
>>> i
>>> know, any function annotated with @CommitAfter will create a new
>>> transaction
>>> similar to EJB required_new. But how would the nested functions
>>> behave?
>>>
>>> For eg.
>>>
>>> @CommitAfter
>>> public void functionA() {
>>> functionB();
>>> }
>>>
>>> @CommitAfter
>>> public void functionB() {}
>>>
>>>
>>> If functionB failed to commit:
>>> 1) Will functionA be rollback?
>>> 2) Or will functionA be commited under another new transaction
>>> regardless
>>> of
>>> functionB?
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23716428.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>>
>>
>
> --
> View this message in context: http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23718188.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by sodium <so...@yahoo.com>.
Thanks Igor,
I think i understand it now. Basically every function which is annotated
with @CommitAfter will be commited at the end of the request when session is
detached. I guess the only way is to group together whatever i wanted to
achieve into a single function and have it @CommitAfter.
Igor Drobiazko wrote:
>
> @CommitAfter commits the transaction of the request. The transaction is
> created when the session is attached to the request. When functionB() is
> called the transaction will be committed and a new one will be created. So
> functionA() will commit the later transaction.
>
> On Tue, May 26, 2009 at 5:46 AM, sodium <so...@yahoo.com> wrote:
>
>>
>> A quick question about tapestry-hibernate rollback propagation. As far as
>> i
>> know, any function annotated with @CommitAfter will create a new
>> transaction
>> similar to EJB required_new. But how would the nested functions behave?
>>
>> For eg.
>>
>> @CommitAfter
>> public void functionA() {
>> functionB();
>> }
>>
>> @CommitAfter
>> public void functionB() {}
>>
>>
>> If functionB failed to commit:
>> 1) Will functionA be rollback?
>> 2) Or will functionA be commited under another new transaction regardless
>> of
>> functionB?
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23716428.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
>
>
--
View this message in context: http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23718188.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @CommitAfter rollback propagation
Posted by Igor Drobiazko <ig...@gmail.com>.
@CommitAfter commits the transaction of the request. The transaction is
created when the session is attached to the request. When functionB() is
called the transaction will be committed and a new one will be created. So
functionA() will commit the later transaction.
On Tue, May 26, 2009 at 5:46 AM, sodium <so...@yahoo.com> wrote:
>
> A quick question about tapestry-hibernate rollback propagation. As far as i
> know, any function annotated with @CommitAfter will create a new
> transaction
> similar to EJB required_new. But how would the nested functions behave?
>
> For eg.
>
> @CommitAfter
> public void functionA() {
> functionB();
> }
>
> @CommitAfter
> public void functionB() {}
>
>
> If functionB failed to commit:
> 1) Will functionA be rollback?
> 2) Or will functionA be commited under another new transaction regardless
> of
> functionB?
>
>
> --
> View this message in context:
> http://www.nabble.com/%40CommitAfter-rollback-propagation-tp23716428p23716428.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko