Rails - Feb 2009 - if one has a nested transaction does the outer-most transaction take precedence?

Hi,

Anyone know, if I have a nested transaction, will it be the outer most
transaction (i.e. from outermost transaction start, to outermost
transaction end) that will be used?

i.e. noting Rails doesn''t currently support nested transactions.
Another way to ask would be to say, if there was a database statement
error between the end of the innermost transaction and the end of the
outmost transaction, would the innermost transaction database
statements be rolled back?

-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 5 Feb 2009, at 11:47, Greg Hauptmann wrote:
>
> Hi,
>
> Anyone know, if I have a nested transaction, will it be the outer most
> transaction (i.e. from outermost transaction start, to outermost
> transaction end) that will be used?
>
> i.e. noting Rails doesn''t currently support nested transactions.
> Another way to ask would be to say, if there was a database statement
> error between the end of the innermost transaction and the end of the
> outmost transaction, would the innermost transaction database
> statements be rolled back?
THis is probably database dependant but on mysql at least a nested  
begin will commit the existing transaction and begin a new one (which  
is why rails is careful not to start a new actual transaction in this  
case). rails 2.3 supports savepoints for what it''s worth.

Fred
>
>
> -- 
> Greg
> http://blog.gregnet.org/
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

thanks - so this means for the moment at least (until v2.3) one has to
be careful re having a method with a transaction begin, that within
may call another method that itself has a transaction begin.  So
really group your methods into ones that use & don''t use
transactions
explicitly I guess...

2009/2/5 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
> On 5 Feb 2009, at 11:47, Greg Hauptmann wrote:
>
>>
>> Hi,
>>
>> Anyone know, if I have a nested transaction, will it be the outer most
>> transaction (i.e. from outermost transaction start, to outermost
>> transaction end) that will be used?
>>
>> i.e. noting Rails doesn''t currently support nested
transactions.
>> Another way to ask would be to say, if there was a database statement
>> error between the end of the innermost transaction and the end of the
>> outmost transaction, would the innermost transaction database
>> statements be rolled back?
>
> THis is probably database dependant but on mysql at least a nested
> begin will commit the existing transaction and begin a new one (which
> is why rails is careful not to start a new actual transaction in this
> case). rails 2.3 supports savepoints for what it''s worth.
>
> Fred
>>
>>
>> --
>> Greg
>> http://blog.gregnet.org/
>>
>> >
>
>
> >
>


-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 5 Feb 2009, at 20:03, Greg Hauptmann wrote:
>
> thanks - so this means for the moment at least (until v2.3) one has to
> be careful re having a method with a transaction begin, that within
> may call another method that itself has a transaction begin.  So
> really group your methods into ones that use & don''t use
transactions
> explicitly I guess...
>
You''re ok if you''re not doing things by hand: if you do

Foo.transaction do
   Foo.transaction do
     ...
   end
end

then the inner call to transaction is basically a no-op.

Fred

> 2009/2/5 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>>
>> On 5 Feb 2009, at 11:47, Greg Hauptmann wrote:
>>
>>>
>>> Hi,
>>>
>>> Anyone know, if I have a nested transaction, will it be the outer  
>>> most
>>> transaction (i.e. from outermost transaction start, to outermost
>>> transaction end) that will be used?
>>>
>>> i.e. noting Rails doesn''t currently support nested
transactions.
>>> Another way to ask would be to say, if there was a database  
>>> statement
>>> error between the end of the innermost transaction and the end of  
>>> the
>>> outmost transaction, would the innermost transaction database
>>> statements be rolled back?
>>
>> THis is probably database dependant but on mysql at least a nested
>> begin will commit the existing transaction and begin a new one (which
>> is why rails is careful not to start a new actual transaction in this
>> case). rails 2.3 supports savepoints for what it''s worth.
>>
>> Fred
>>>
>>>
>>> --
>>> Greg
>>> http://blog.gregnet.org/
>>>
>>>>
>>
>>
>>>
>>
>
>
>
> -- 
> Greg
> http://blog.gregnet.org/
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

ok  - so just to be clear then, statement A will rollback if there is
an issue with the statement B?  this is at least good then for me

Foo.transaction do
  Foo.transaction do
     statement A
    ...
  end
  statement B
end


2009/2/6 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
> On 5 Feb 2009, at 20:03, Greg Hauptmann wrote:
>
>>
>> thanks - so this means for the moment at least (until v2.3) one has to
>> be careful re having a method with a transaction begin, that within
>> may call another method that itself has a transaction begin.  So
>> really group your methods into ones that use & don''t use
transactions
>> explicitly I guess...
>>
> You''re ok if you''re not doing things by hand: if you do
>
> Foo.transaction do
>   Foo.transaction do
>     ...
>   end
> end
>
> then the inner call to transaction is basically a no-op.
>
> Fred
>
>
>> 2009/2/5 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>
>>>
>>> On 5 Feb 2009, at 11:47, Greg Hauptmann wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> Anyone know, if I have a nested transaction, will it be the
outer
>>>> most
>>>> transaction (i.e. from outermost transaction start, to
outermost
>>>> transaction end) that will be used?
>>>>
>>>> i.e. noting Rails doesn''t currently support nested
transactions.
>>>> Another way to ask would be to say, if there was a database
>>>> statement
>>>> error between the end of the innermost transaction and the end
of
>>>> the
>>>> outmost transaction, would the innermost transaction database
>>>> statements be rolled back?
>>>
>>> THis is probably database dependant but on mysql at least a nested
>>> begin will commit the existing transaction and begin a new one
(which
>>> is why rails is careful not to start a new actual transaction in
this
>>> case). rails 2.3 supports savepoints for what it''s worth.
>>>
>>> Fred
>>>>
>>>>
>>>> --
>>>> Greg
>>>> http://blog.gregnet.org/
>>>>
>>>>>
>>>
>>>
>>>>
>>>
>>
>>
>>
>> --
>> Greg
>> http://blog.gregnet.org/
>>
>> >
>
>
> >
>


-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 6 Feb 2009, at 00:25, Greg Hauptmann wrote:
>
> ok  - so just to be clear then, statement A will rollback if there is
> an issue with the statement B?  this is at least good then for me
>
> Foo.transaction do
>  Foo.transaction do
>     statement A
>    ...
>  end
>  statement B
> end
>
Correct. The above is equivalent to

Foo.transaction do
  statement A
  statement B
end

(Again assuming you''re not using 2.3''s savepoint support
(which is
turned off by default I believe))

Fred
>
> 2009/2/6 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>>
>> On 5 Feb 2009, at 20:03, Greg Hauptmann wrote:
>>
>>>
>>> thanks - so this means for the moment at least (until v2.3) one  
>>> has to
>>> be careful re having a method with a transaction begin, that within
>>> may call another method that itself has a transaction begin.  So
>>> really group your methods into ones that use & don''t
use
>>> transactions
>>> explicitly I guess...
>>>
>> You''re ok if you''re not doing things by hand: if you
do
>>
>> Foo.transaction do
>>  Foo.transaction do
>>    ...
>>  end
>> end
>>
>> then the inner call to transaction is basically a no-op.
>>
>> Fred
>>
>>
>>> 2009/2/5 Frederick Cheung
<frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>
>>>>
>>>> On 5 Feb 2009, at 11:47, Greg Hauptmann wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Anyone know, if I have a nested transaction, will it be the
outer
>>>>> most
>>>>> transaction (i.e. from outermost transaction start, to
outermost
>>>>> transaction end) that will be used?
>>>>>
>>>>> i.e. noting Rails doesn''t currently support nested
transactions.
>>>>> Another way to ask would be to say, if there was a database
>>>>> statement
>>>>> error between the end of the innermost transaction and the
end of
>>>>> the
>>>>> outmost transaction, would the innermost transaction
database
>>>>> statements be rolled back?
>>>>
>>>> THis is probably database dependant but on mysql at least a
nested
>>>> begin will commit the existing transaction and begin a new one
>>>> (which
>>>> is why rails is careful not to start a new actual transaction
in
>>>> this
>>>> case). rails 2.3 supports savepoints for what it''s
worth.
>>>>
>>>> Fred
>>>>>
>>>>>
>>>>> --
>>>>> Greg
>>>>> http://blog.gregnet.org/
>>>>>
>>>>>>
>>>>
>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Greg
>>> http://blog.gregnet.org/
>>>
>>>>
>>
>>
>>>
>>
>
>
>
> -- 
> Greg
> http://blog.gregnet.org/
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---