Rails core - Jul 2008 - Move transaction counter from Thread.current to the connection object

I''ve updated the patch for the ticket at
http://dev.rubyonrails.org/ticket/10212.

New ticket here:

http://rails.lighthouseapp.com/projects/8994/tickets/533-fix-nested-transactions-across-multiple-databases

It moves the counter for the number of open transactions from Thread.current
(which seems a very odd place to keep it), to the connection object. This
means that transactions across multiple database connections can be properly
supported.

Comments please.

Cheers,
-Jonathan.

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

Anyone able to look at, comment on, or apply this ticket?

On Wed, Jul 2, 2008 at 5:43 PM, Jonathan Viney <jonathan.viney@gmail.com>
wrote:
> I''ve updated the patch for the ticket at
> http://dev.rubyonrails.org/ticket/10212.
>
> New ticket here:
>
>
>
http://rails.lighthouseapp.com/projects/8994/tickets/533-fix-nested-transactions-across-multiple-databases
>
> It moves the counter for the number of open transactions from
> Thread.current (which seems a very odd place to keep it), to the connection
> object. This means that transactions across multiple database connections
> can be properly supported.
>
> Comments please.
>
> Cheers,
> -Jonathan.
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Tue, Jul 15, 2008 at 1:27 PM, Jonathan Viney
<jonathan.viney@gmail.com> wrote:
> Anyone able to look at, comment on, or apply this ticket?
Transactions across multiple database connections won''t really
''work''
with this will they?  an error in one won''t roll back the other and
you don''t get transactional guarantees like you would with a full two
phase commit.  Are there any other functional benefits?

However, the connection handling code is pretty gross and Nick Sieger
from the jruby guys has been looking at refactoring it to use a
connection pool.  I''d try to touch base with him and get this merged
into his branch which will eventually make its way into the mainline.


-- 
Cheers

Koz

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

Quite right, they won''t be fully functional in that sense, but it is
certainly an improvement. An exception in the inner transaction will cause
the outer one to rollback as long as it isn''t caught and discarded (as
the
test shows).

This change at least makes multi-database transactions usable for those who
need it. Also, according to the original Trac ticket (
http://dev.rubyonrails.org/ticket/10212), this used to work before Rails
2.0.

-Jonathan.

On Tue, Jul 15, 2008 at 11:34 PM, Michael Koziarski
<michael@koziarski.com>
wrote:
>
> On Tue, Jul 15, 2008 at 1:27 PM, Jonathan Viney
> <jonathan.viney@gmail.com> wrote:
> > Anyone able to look at, comment on, or apply this ticket?
>
> Transactions across multiple database connections won''t really
''work''
> with this will they?  an error in one won''t roll back the other
and
> you don''t get transactional guarantees like you would with a full
two
> phase commit.  Are there any other functional benefits?
>
> However, the connection handling code is pretty gross and Nick Sieger
> from the jruby guys has been looking at refactoring it to use a
> connection pool.  I''d try to touch base with him and get this
merged
> into his branch which will eventually make its way into the mainline.
>
>
> --
> Cheers
>
> Koz
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---