|
Posted by Bernard Cosell on January 7, 2005, 1:01 pm
Please log in for more thread options
This is a part-Unix, part-Perl problem (and indeed, at the moment I
don't really know how to do either..:o)): What we need to do is pass
an open DBI connection between Unix processes. [we'll be in the
middle of a (DBI) transaction and we need the second process to be
able to "continue" the transaction and the actual commit will happen
in the second process [if we can figure out how to do this]].
anyone ever seen or have any idea on how to do something like this?
The processes are NOT parent/forkedchild related, so copying FDs and
such isn't an option. The best I've been able to come up with at the
moment is to write a "DBD proxy" -- a new DBD driver that'll actually
open a connection to a local daemon and it'd be the daemon that wouild
open the 'real' connection to the database... and then [if I can
figure out how] act as a full-proxy between that connection and the
actual DB connection [and then allow another process, using the same
DBD driver, to link up with that same connection]. Seems complicated,
but doable.
Any thoughts, suggestions, CPAN modules I missed, etc. would be
appreicates... THANKS!
/Bernie
|
|
Posted by Bernard Cosell on January 7, 2005, 2:47 pm
Please log in for more thread options
wrote:
>This is a part-Unix, part-Perl problem (and indeed, at the moment I
>don't really know how to do either..:o)): What we need to do is pass
>an open DBI connection between Unix processes.
Further poking through CPAN, reading more random docs, etc, I
blundered across what seems to be the perfect solution: there is a
DBD::Proxy module that does _exactly_ what we want [even includes a
'server' that can cache the behind-the-scenes real DB connections
across separate processes, just as I need].
So I think I'm set...:o) /bernie
|
|
Posted by Steven N. Hirsch on January 8, 2005, 9:21 pm
Please log in for more thread options Bernard Cosell wrote:
> wrote:
>
>
>>This is a part-Unix, part-Perl problem (and indeed, at the moment I
>>don't really know how to do either..:o)): What we need to do is pass
>>an open DBI connection between Unix processes.
>
>
> Further poking through CPAN, reading more random docs, etc, I
> blundered across what seems to be the perfect solution: there is a
> DBD::Proxy module that does _exactly_ what we want [even includes a
> 'server' that can cache the behind-the-scenes real DB connections
> across separate processes, just as I need].
It may cache the _connection_, but if I'm understanding your original
post you need the ability to pass a _session_ (with active UOW) to
another process. Correct? I don't think DBD::Proxy has any way to
accomplish that.
|
|
Posted by Brian McCauley on January 7, 2005, 6:26 pm
Please log in for more thread options
Bernard Cosell wrote:
> This is a part-Unix, part-Perl problem (and indeed, at the moment I
> don't really know how to do either..:o)): What we need to do is pass
> an open DBI connection between Unix processes. [we'll be in the
> middle of a (DBI) transaction and we need the second process to be
> able to "continue" the transaction and the actual commit will happen
> in the second process [if we can figure out how to do this]].
The DBD driver inteface only describes the communication between the
generic DBI layer and the database specific DBD layer. It does not
constrain how the DBD driver talks to the database. Could be shared
memory, unix sockets, TCP sockets, UDP sockets, e-mail...
> anyone ever seen or have any idea on how to do something like this?
You cannot do it directly except for a single DBD and how you'd do it
would depend on the implelemtation of the DBD.
> The processes are NOT parent/forkedchild related, so copying FDs and
> such isn't an option.
Er, why not? Without a mechanism to pass about open filehandles this is
going to be really colplicated.
> The best I've been able to come up with at the
> moment is to write a "DBD proxy" -- a new DBD driver that'll actually
> open a connection to a local daemon and it'd be the daemon that wouild
> open the 'real' connection to the database... and then [if I can
> figure out how] act as a full-proxy between that connection and the
> actual DB connection [and then allow another process, using the same
> DBD driver, to link up with that same connection]. Seems complicated,
> but doable.
Most of that already exists - there is already a DBD::Proxy.
If you did the above mentioned job for DBD::Proxy then you could then
use it for any underlying DBD via the proxy.
I also recall Tim Bunce saying that the DBD driver interface was going
to provide a means for the driver to produce a serialised version of its
state that could be passed about between multiple Perl processor threads
to support Apache+mod_perl2. This mechanism however assumes that the
underlying OS filedescriptors are already shared. It would not be a
huge step to extend it so that the filedescriptors could be passed.
This still will only help if the DBD supports this new functionality.
|
|
Posted by Bernard Cosell on January 7, 2005, 2:51 pm
Please log in for more thread options wrote:
>Bernard Cosell wrote:
>
>> This is a part-Unix, part-Perl problem (and indeed, at the moment I
>> don't really know how to do either..:o)): What we need to do is pass
>> an open DBI connection between Unix processes....
>> The processes are NOT parent/forkedchild related, so copying FDs and
>> such isn't an option.
>
>Er, why not? Without a mechanism to pass about open filehandles this is
>going to be really colplicated.
Well, on Unix [AFAIK] it isn't possible to pass around FDs between
unrelated processes [the only way I know of to get an FD from one
process to another is to have it copied by the OS in a fork() call].
>> The best I've been able to come up with at the
>> moment is to write a "DBD proxy" -- a new DBD driver that'll actually
>> open a connection to a local daemon and it'd be the daemon that wouild
>> open the 'real' connection to the database... ...
>Most of that already exists - there is already a DBD::Proxy.
>
>If you did the above mentioned job for DBD::Proxy then you could then
>use it for any underlying DBD via the proxy.
That's what I'm going to do -- I found DBD::Proxy myself just a few
moments before seeing your post here about it..:o)
>I also recall Tim Bunce saying that the DBD driver interface was going
>to provide a means for the driver to produce a serialised version of its
>state that could be passed about between multiple Perl processor threads
>to support Apache+mod_perl2. This mechanism however assumes that the
>underlying OS filedescriptors are already shared. It would not be a
>huge step to extend it so that the filedescriptors could be passed.
A really big problem with Unix, and so the best solution is to use
paired-named-pipes or sockets to communicate to a proxy-server [via
DBD::Proxy] and then have the proxy server open/hold the *real* DB
connection [via DBD::whatever]
/Bernie
|
| Similar Threads | Posted | | Need help with a simple UNIX sockets server based on IO::Socket::UNIX | April 14, 2005, 3:02 am |
| mod_perl and access to the parent processes environment? | July 19, 2006, 4:41 pm |
| Killing all the child processes created through Expect module | December 9, 2004, 4:58 am |
| No connection using LWP | October 27, 2006, 5:30 pm |
| Options for passing Hash to a subroutine. | March 30, 2005, 7:39 pm |
| mod_perl2 passing env vars when doing internal_redirects | July 11, 2005, 8:24 am |
| Passing username and password using LWP::UserAgent | December 11, 2006, 4:40 am |
| Net::FTP connection status | March 15, 2006, 3:34 am |
| net::sftp connection close | May 4, 2006, 6:27 am |
| NET::SFTP - how to close connection | September 28, 2006, 7:22 am |
|
XML Sitemap