Re: passing mysql dbi handle from parent to child
bruce wrote: to begin... I've reconnected this thread to DBI Users - other people there may benefit from this information, and a different set of other people may have useful advice to offer. i'm considering an app that would require transactional processing across multiple web pages of an app... if each page created it's own connection, then one couldn't really do transactional processing where various db functions are occuring on each page, with the final/all interactions being accepted if all actions are successful. keep in mind, once a page closes, so does it's connection, which means that any db interactions are also gone. ie, you can't use commit/rollback across multiple pages... Transactions across multiple (web) pages are a common problem. There are various solutions, I believe, but very few if any of them involve sharing a single database connection across the multiple pages. the ability of a persistent/connection or pool of connection ids would solve this. mysql/php4 had persistent connections. mysql4.1.3/php5 does not... can we potentially rethink our design, sure.. I think you may have to do so. does that limit what web apps can do regarding complex transactions, mos def... The very nature of the web is that all http requests are (nominally) independent of each other. There are endless ways of providing continuity across requests. I believe, but stand to be shown incorrect, that the general mechanism is to treat each page's operations as some sort of transaction step that is recorded in a table of some sort, with the next step adding to that data, and so on until all the data has been collected and the final transaction can be placed into the main operational tables. That does not seem to limit the transactional complexity of web applications. A bigger problem with your proposed/preferred solution, at least for intensively used sites, is that each session has its own database connection, despite the fact most of those sessions are idle most of the time - they are occupying database resources, and possibly locking each other, and generally it is not very efficient. the goal would be to create an initial id, with each subsequent page of a given session using the id. each session would create/use it's own id... this solves your concern for multiple people accessing the db... the middleware logic would have to take alot into account to be robust for general usage. i'm not worried about that.. right now, my primary issue is how to actually pass a dbi handle from a parent to child using perl! And, as I said earlier, in general it is impossible. I can't come out and say in DBD::MySQL it is impossible because I don't know that for sure. But I do think it is unlikely to be possible - extremely unlikely. There has been frequent discussion about whether it is possible to share a database handle across forked processes. I believe that the consensus is that the answer is No, especially for programs written with a scintilla of portability. It does depend somewhat on the nature of the driver, but the two-process architecture for the typical DBMS makes such sharing unreliable if it works at all. i suspect that it is possible to accomplish... right now, there appears to be something weird with regards to my simply doing a 'exec child.pl $dbh'... IMNSHO, it is weird that you would expect that an address created in the parent process should have the same significance in the child process - let alone the issues of resources associated with that address in the parent. I wish you luck, but I think you're trying to do the unattainable. Please address further questions to [EMAIL PROTECTED] and not to me. -Original Message- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Sunday, August 01, 2004 8:27 PM To: [EMAIL PROTECTED] Subject: Re: passing mysql dbi handle from parent to child bruce wrote: i'm in need of a solution for a type of connection pooling for mysql... OK - does MySQL provide connection pooling? Why do you need connection pooling? if i can create the dbi connection handle, i should be able to pass it to a child process On what basis do you think that? (i hope) as long as the original parent process that created the handle is still alive. The problems here are legion. There are sharing issues - what happens if the parent tries to send a message at the same time that the child does? Which of them gets to read the answer? But that jumps the gun; how does the child's MySQL library know that a particular file descriptor that it inherited is a MySQL connection that it can use? There most likely is no mechanism to do so. the concern i have is that the parent process id might be somehow tied to the dbi connection handle/link... That might be part of the problem - DBD::Informix will explicitly include such a check precisely because inherited connections - even across a fork, let alone an exec as you plan to use - do not work reliably.
Re: passing mysql dbi handle from parent to child
On Mon, Aug 02, 2004 at 12:07:45AM -0700, Jonathan Leffler wrote: i suspect that it is possible to accomplish... I don't. right now, there appears to be something weird with regards to my simply doing a 'exec child.pl $dbh'... It only appears to be weird because you don't have a clear understanding of the issues. See http://www.catb.org/~esr/faqs/smart-questions.html IMNSHO, it is weird that you would expect that an address created in the parent process should have the same significance in the child process - let alone the issues of resources associated with that address in the parent. I wish you luck, but I think you're trying to do the unattainable. Please address further questions to [EMAIL PROTECTED] and not to me. You won't get far with this particular issue on [EMAIL PROTECTED] Best to step back and start approaching the issue with fresh eyes. Tim.
Free to wrong pool using dbi, mysql, activestate perl 510
morning,
i'm trying to track down a bug that we're experiencing in bugzilla.
http://bugzilla.mozilla.org/show_bug.cgi?id=253696
on activestate perl (windows) build 510 when i connect to a mysql database
specifying using
FetchHashKeyName = 'NAME_lc'
and run selectall_hashref() i get
Free to wrong pool 223f88 not ff at e:/Perl/site/lib/DBI.pm line 1867.
my $dbh = DBI-connect(
DBI:mysql:host=localhost;database=bugs;port=3306, '', '',
{ Username = 'bugs', Password = '', FetchHashKeyName = 'NAME_lc', }
) or die $!;
my $days_since_epoch = int(time() / (60 * 60 * 24));
my $serieses = $dbh-selectall_hashref(SELECT series_id, query, creator .
FROM series .
WHERE frequency != 0 AND .
($days_since_epoch + series_id) % frequency = 0,
series_id
);
on activestate perl 5.8.3 build 809, it does not crash.
nor does it crash if i set FetchHashKeyName to 'NAME' (or don't set it).
any ideas?
thanks,
byron
begin-base64 644 signature.gif
R0lGODlhbQAHAIBPoywAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
Re: Help with DB2 DBI Connection
On July 29, 2004 9:53 am, Jay harris wrote: I am onsite at a client, and they use AIX/DB2-UDB V8. They have an automated scheduling package that starts jobs using su super user, and then passes the account like a nohup would do. My problem is that the dbi connect seems to require a password, but I do not have access to the password. They (the company) will not give the users access to run production jobs that connect to the database. Is there a way to connect without a password. My Unix shell scripts can connect because when the DB2 command is issued it defaults to the logged on user. Any help would be greatly appreciated. What user are you su'ing to? That's the user that needs to be GRANTed access to the database. (Hopefully, it's not a user with uid=0.)
ANNOUNCE: Advanced DBI tutorial slides
I uploaded the slides for my Advanced DBI tutorial shortly before OSCON but forgot to announce them: file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_2004.tar.gz size: 3122405 bytes md5: b8a8f1732a0d67c6c69e48e4541c3162 Most easily read online via: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm you'll also find some mention of DBI v2 here: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld097.htm Tim.
Re: Free to wrong pool using dbi, mysql, activestate perl 510
on activestate perl (windows) build 510 when i connect to a mysql database specifying using FetchHashKeyName = 'NAME_lc' and run selectall_hashref() i get Free to wrong pool 223f88 not ff at e:/Perl/site/lib/DBI.pm line 1867. on activestate perl 5.8.3 build 809, it does not crash. oops, 5.8.2 build 808 does not crash, 5.8.3 build 809 does. begin-base64 644 signature.gif R0lGODlhbQAHAIBPoywAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw==
Re: ANNOUNCE: Advanced DBI tutorial slides
Tim, is DBI v2 going to coincide with the release of the 2nd edition of Programming the Perl DBI? Hardy Merrill [EMAIL PROTECTED] 08/02/04 10:31AM I uploaded the slides for my Advanced DBI tutorial shortly before OSCON but forgot to announce them: file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_2004.tar.gz size: 3122405 bytes md5: b8a8f1732a0d67c6c69e48e4541c3162 Most easily read online via: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm you'll also find some mention of DBI v2 here: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld097.htm Tim.
RE: ANNOUNCE: Advanced DBI tutorial slides
I see some references to v2 several times in this list, but don't know the real state of it and I'm curious. So, is there a v2 in-process or is it just an idea for now? And when will we see a first release (alpha/beta/final)? -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 5:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: ANNOUNCE: Advanced DBI tutorial slides I uploaded the slides for my Advanced DBI tutorial shortly before OSCON but forgot to announce them: file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_2004.tar.gz size: 3122405 bytes md5: b8a8f1732a0d67c6c69e48e4541c3162 Most easily read online via: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm you'll also find some mention of DBI v2 here: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld097.htm Tim.
Re: DBD::Translate
On Fri, Jul 30, 2004 at 05:14:27PM -0700, Masahji Stewart wrote:
Hey Tim,
I had a question about a module that I was designing to do SQL
translation between databases. I was going to implement it as a
database driver (DBD::Translate). Here's how it would be used:
The core translation code ought to live outside the DBI in an SQL::*
module so it's reusable in other contexts.
That module could then be used either by a DBI subclass, or by a
layered driver such as the DBD::Translate you're proposing.
The new version of DBD::Multiplex that'll be included in DBI v2 will
have hooks for callbacks that can be used for SQL translation.
Your SQL::* translation module could be easily plugged in that way.
Tim.
code
use DBI;
my $real_handle = DBI-connect('dbi:mysql:localhost', 'username',
'password');
# this means the underlying DBD::Translate module will parse oracle
queries
# and convert them to whatever database that the $real_handle is
configured
to use (mysql).
my $translate_handle = DBI-connect('dbi:translate:oracle',
$real_handle);
# obviously an Oracle query which will now be executing on the mysql
database from the handle above.
my $sth = $translate_handle-prepare('SELECT DECODE(user_id, NULL, '0',
user_id) FROM users');
$sth-execute();
while( my $row = $sth-fetchrow_hashref ) {
# ...
}
/code
After looking around at your DBI TODO list, I noticed that the
$dbh-preparse method seems like this. I think. What exactly does the
preparse method do? is it anything like this?
If so, will you require the driver implementers to handle the parsing
of their own language?
Please let me know and thanks in advance,
-masahji
Re: ANNOUNCE: Advanced DBI tutorial slides
On Mon, Aug 02, 2004 at 06:20:57PM +0300, Burak Gursoy wrote: I see some references to v2 several times in this list, but don't know the real state of it and I'm curious. So, is there a v2 in-process or is it just an idea for now? And when will we see a first release (alpha/beta/final)? Currently it's an idea. How quickly it moves from idea to alpha depends on the availability of my time. (From alpha to beta to final also depends on the level of contributions from others.) Hardy Merrill wrote: : Tim, is DBI v2 going to coincide with the release of the 2nd edition of : Programming the Perl DBI? I certainly expect DBI v2 to be in widespread use a long time before the 2nd edition of the book is available. Tim. -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 5:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: ANNOUNCE: Advanced DBI tutorial slides I uploaded the slides for my Advanced DBI tutorial shortly before OSCON but forgot to announce them: file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_2004.tar.gz size: 3122405 bytes md5: b8a8f1732a0d67c6c69e48e4541c3162 Most easily read online via: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm you'll also find some mention of DBI v2 here: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld097.htm Tim.
Re: Free to wrong pool using dbi, mysql, activestate perl 510
On Mon, Aug 02, 2004 at 11:16:09PM +0800, byron jones wrote: on activestate perl (windows) build 510 when i connect to a mysql database specifying using FetchHashKeyName = 'NAME_lc' and run selectall_hashref() i get Free to wrong pool 223f88 not ff at e:/Perl/site/lib/DBI.pm line 1867. on activestate perl 5.8.3 build 809, it does not crash. oops, 5.8.2 build 808 does not crash, 5.8.3 build 809 does. Dig around in here and see what you can find: http://www.google.com/search?hl=enlr=ie=UTF-8safe=offas_qdr=allq=+%22Free+to+wrong+pool%22+perl5-portersbtnG=Search Tim.
Re: ANNOUNCE: Advanced DBI tutorial slides
Tim Bunce wrote:
I uploaded the slides for my Advanced DBI tutorial shortly before OSCON
but forgot to announce them:
However, they didn't escape our attention. :-)
http://www.perlmonks.org/index.pl?node_id=372346
Cheers
gmax
file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_2004.tar.gz
size: 3122405 bytes
md5: b8a8f1732a0d67c6c69e48e4541c3162
Most easily read online via:
http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm
you'll also find some mention of DBI v2 here:
http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld097.htm
Tim.
--
_ _ _
/ _ |\( ( \ / )
( (_| | | | / ___ |) X (
\___ |_|_|_\_(_/ \_)
(_|
Sapere, saper fare, fare, far sapere
http://gmax.oltrelinux.com
Re: ANNOUNCE: Advanced DBI tutorial slides
Hardy Merrill [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Tim, is DBI v2 going to coincide with the release of the 2nd edition of Programming the Perl DBI? Hardy Merrill That would be cool. I use that book everyday almost. Robert
DBI 2.x and the 'sad hack' for DBD::Informix
DBD::Informix 0.95 introduced the internal tables function; no-one should still be using any earlier versions of DBD::Informix than 1.00.PC1, so the 'sad hack' can go - especially since it actually doesn't work reliably for Informix anyway. I note that the DBI (v1.42 RC1, but I don't think it changed) version does not handle schema names containing quotes: CREATE TABLE .blanketyblank (...); This is a valid table called blanketyblank owned by (belonging to schema) double-quote, double-quote in an ISO-compliant SQL database. Granted, that's kinda esoteric, but if you're worrying about quoting stuff just in case, hadn't you better worry about all the cases that might just occur? -- Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include disclaimer.h Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
