Rogelio, The SERVICES-22 doesn't seems to be a issue for me. The old behavior is the one buggy imho, since a nested transaction context spans it's boundaries and are propagated to the parent transaction.
Cheers, Henry Conceição On Fri, Sep 17, 2010 at 12:24 PM, <[email protected]> wrote: > Bug reported http://issues.castleproject.org/issue/SERVICES-22 > > > > I have also attached a patch file with Unit Test and Fix. > > > > RJB > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, September 16, 2010 11:33 AM > > To: [email protected] > Subject: RE: Different behavior in Trasaction Services in 2.5 > > > > Hi, > > > > The ChildTransaction’s Context functionality has the same problem. The > implementation in 2.5 differs from the old one (1.0...). > > > > Should I submit a bug report? > > > > The different implementations are breaking existing code after the update to > 2.5. > > > > Thanks, > > > > RJB > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Wednesday, September 15, 2010 4:33 PM > To: [email protected] > Subject: Different behavior in Trasaction Services in 2.5 > > > > Hi, > > > > After updating Castle.Services.Transaction.dll to 2.5.0.48 I have found that > synchronization objects registered in child transactions (ChildTransaction > instances) are not been invoked. Looking at the new implementation of this > class I noticed a difference with the previous version of the > Castle.Services.Transaction.dll (1.0.3.5953). In the old version of the > ChildTransaction class registering a synchronization object invokes the > registration in the StandardTransaction instance see the following code: > > > > public override void RegisterSynchronization(ISynchronization > synchronization) > > { > > _parent.RegisterSynchronization(synchronization); > > } > > > > This will go all the way up until a StandardTransaction instance. The new > implementation of ChildTransaction does not override the > RegisterSynchronization implementation from TransactionBase and keeps the > synchronization objects in a local list. Since the Commit method in > ChildTransaction does nothing, those synchronization instances are lost. > > > > Is this the intended behavior? I do not think it is correct… > > > > RJB > > > > > > Rogelio J. Baucells • Technical Architect • SunGard • Investran • 11098 > Biscayne Boulevard, Suite 403, Miami, FL 33161 > Tel +1-305-892-3270 • Fax +1-305-895-0005 • www.sungard.com/investran > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
