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.

Reply via email to