Thanks! That makes sense. I just wanted to make sure I wasn't missing
anything obvious. For now I'll stick with the Thread-based approach
since it's not performance critical and I'd rather not have to modify
every query within the block.
Would it be feasible to develop a Sequel plugin or feature that
changes the default server within the scope of a block? I'd take a
stab at it if you could point me in the right direction.
Something like:
with_server(:fake) do
...
end
On Oct 6, 12:43 pm, Jeremy Evans <[email protected]> wrote:
> On Oct 6, 9:32 am, Jay Stotz <[email protected]> wrote:
>
>
>
>
>
> > I have a block of code that interacts with an external web service and
> > writes the results of its interaction to the database. This code is
> > sometimes called from within a Sequel transaction block. It is
> > critical that the results of the web service interaction be committed
> > to the database even if the outer transaction is rolled back.
>
> > A savepoint is not an option because I want all work performed in the
> > outer transaction to be rolled back in the event of an exception or
> > explicit rollback at any point before or after the web service code is
> > called.
>
> > I got the behavior I want by running the independent transaction in a
> > separate thread but I think there must be a more efficient way to do
> > this. Any suggestions?
>
> > def parallel_transaction(*args, &block)
> > result = nil
> > Thread.new { result = transaction(*args, &block) }.join
> > result
> > end
>
> A separate thread is one way. The other way is to use the sharding
> support with a fake server:
>
> DB = Sequel.connect(..., :servers=>{:fake=>{}})
>
> And use that shard in your transaction:
>
> def parallel_transaction(*args, &block)
> transaction(:server=>:fake, &block)
> end
>
> If you do that, you need to be sure that the queries in the block
> passed to parallel transaction use the fake server (using
> Dataset#server).
>
> Using a separate shard probably performs better, but is a little more
> work. Using a separate thread probably performs worse, but is less
> work.
>
> Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" 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/sequel-talk?hl=en.