I would say that in certain contexts it would definitely be
sane/preferable to have a "worker" process work in its boss's transaction.
In the traditional bank example:
Open a transfer transaction:
One application goes to take money out of one account.
The second application goes to put money into the other account.
A third application might do other things.
This way you can do parallel processing with separate physical
applications, and still keep the integrity of the transaction. The
transaction would then be committed when all of the child applications
came back and reported success and would be rolled back if one reported
a failure.
How to do it is environment specific and I couldn't tell you how to pass
a transaction or connection as a parameter in ruby.
Sim
Wayne Conrad wrote:
> I work with a system designed as lots of little cooperating worker
> programs, with boss programs that... well, boss the worker programs
> around.
>
> Boss and workers all use the same database.
>
> Sometimes it would be convenient to have a boss start a transaction
> and then have the workers do their work in the context of that
> transaction.
>
> Each time, I've decided that since I don't know how to do that, that I
> never really wanted to do that. You know how it goes.
>
> Today, it would once again be convenient to have an exec'd program do
> its work in the context of its parent program's transaction. So,
> before I once again decide that I don't actually want to do that, can
> you tell me... is it possible? And, would any sane person do it?
>
> We're using Linux. All of the programs are written in Ruby 1.8, using
> the venerable (or is it just ancient?) pgsql library.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
