On Jan 4, 2007, at 4:36 PM, Perrin Harkins wrote:
On Thu, 2007-01-04 at 16:28 -0800, Lev Lvovsky wrote:
Is there anything that would keep me from instituting the connection
maintenance of Apache::DBI into a daemonized perl script?
Don't do that. Use DBI->connect_cached instead.
didn't eve
On Thu, 2007-01-04 at 16:28 -0800, Lev Lvovsky wrote:
> Is there anything that would keep me from instituting the connection
> maintenance of Apache::DBI into a daemonized perl script?
Don't do that. Use DBI->connect_cached instead.
- Perrin
Hello,
Is there anything that would keep me from instituting the connection
maintenance of Apache::DBI into a daemonized perl script? Does it
have any need to be running from within mod_perl specifically?
If not, is it just as easy as doing a 'use Apache::DBI' before 'use
DBI'?
thanks!
On Sep 7, 2006, at 4:40 PM, Jay Buffington wrote:
This solves a problem I was having some time ago while implementing
ecommerce (verisign):
1. insert customer's info
2. authorize credit card
3. log authorization response to database
4. if auth fails roll back #1, but keep #3
Nested transact
This solves a problem I was having some time ago while implementing
ecommerce (verisign):
1. insert customer's info
2. authorize credit card
3. log authorization response to database
4. if auth fails roll back #1, but keep #3
I was planning on solving this problem using Oracle's
AUTONOMOUS_TRAN
take a look at:
http://search.cpan.org/~crakrjack/DBIx-Transaction-0.008/
which allows for nested transactions in a DBI handle.
I use something homegrown and similar (but not stable enough for
cpan), that intercepts calls to connect/disconnect and treats them as
begin/end commands
On Thu, 2006-09-07 at 12:29 -0700, Jay Buffington wrote:
> But, that handle might have expired, so it is possible to get a
> different handle.
It's not likely, but it is possible. You'd need to have some transient
error that caused the connection to die between DBI calls. (Not during
a call, sin
Reviving a thread 4 months later...
On 5/10/06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
On Wed, 2006-05-10 at 10:26 -0700, Jay Buffington wrote:
> At first I was caching the database handle myself when running outside
> of mod_perl. In mod_perl I was relying on Apache::DBI returning the
> sam
On Wed, 2006-05-10 at 10:26 -0700, Jay Buffington wrote:
> At first I was caching the database handle myself when running outside
> of mod_perl. In mod_perl I was relying on Apache::DBI returning the
> same handle every time I called connect(). That didn't work.
What didn't work about it? If yo
On May 10, 2006, at 1:26 PM, Jay Buffington wrote:
I want my modules to be able to get a the same database handle
anywhere they need it during a single request (if under mod_perl) or
the life time of the script they're in.
At first I was caching the database handle myself when running outside
I want my modules to be able to get a the same database handle
anywhere they need it during a single request (if under mod_perl) or
the life time of the script they're in.
At first I was caching the database handle myself when running outside
of mod_perl. In mod_perl I was relying on Apache::DBI
On Mon, 2006-05-08 at 17:23 +0200, Lionel MARTIN wrote:
> I'm not sure this is right. Acording to what I read, and to my test, the
> PerlInitHandler phase happens for every request, and not just when threads
> are created.
I called it PerlInitHandle, but it's actually called
PerlChildInitHandler
rkins" <[EMAIL PROTECTED]>
To: "Lionel MARTIN" <[EMAIL PROTECTED]>
Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>;
Sent: Monday, May 08, 2006 5:00 PM
Subject: Re: Using Apache::DBI
On Mon, 2006-05-08 at 16:56 +0200, Lionel MARTIN wrote:
And what a
On Mon, 2006-05-08 at 16:56 +0200, Lionel MARTIN wrote:
> And what about the best usage when using threaded MPMs, like Win32 MPMs,
> concerning connections?
It's no different. The threads are created after startup, and the init
phase happens in each thread.
- Perrin
And what about the best usage when using threaded MPMs, like Win32 MPMs,
concerning connections?
- Original Message -
From: "Perrin Harkins" <[EMAIL PROTECTED]>
To: "Octavian Rasnita" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, May 08, 2006 3:26 P
Octavian Rasnita wrote:
I thought the best way of using Apache::DBI is to put the following code in
the startup.pl script:
use Apache::DBI ();
Apache::DBI->connect_on_init('DBI:mysql:database=database_name;host=10.50.28
.37', 'user', undef, {PrintError => 1, RaiseE
Hi,
I thought the best way of using Apache::DBI is to put the following code in
the startup.pl script:
use Apache::DBI ();
Apache::DBI->connect_on_init('DBI:mysql:database=database_name;host=10.50.28
.37', 'user', undef, {PrintError => 1, RaiseError => 0, AutoComm
On Aug 18, 2005, at 5:55 PM, David Hodgkinson wrote:
But you're still trying to optimise prematurely.
I'll need to to a lot of optimizing in the future - but I just want to
avoid as many obvious mistakes as possible and compartmentalize where
the mistakes are made so I can find them qui
On 18 Aug 2005, at 18:58, Jonathan Vanasco wrote:
i'm thinking about moving to pgsql for stored procedures too (yes
my5 has it, but its beta), but thats an entirely OT discussion.
And you have pgpool too.
But you're still trying to optimise prematurely.
Treat your fat apaches as application
On Aug 18, 2005, at 1:42 PM, Perrin Harkins wrote:
If you can figure out a way to do
that, you could theoretically have a separate process managing a pool
of
them. I doubt it would be worth it though.
That's pretty much what I was thinking, but I didn't really want to do
this in a situat
On Thu, 2005-08-18 at 13:31 -0400, Jonathan Vanasco wrote:
> I didn't see anything about DBI connections in the guide about that.
It's one of the primary reasons to use a front-end server.
I'm afraid your idea won't work because most databases don't support
passing handles across processes. If y
I'm front-ending with lighttpd right now (originally was apache, but I
moved over) and limiting with maxclients
I didn't see anything about DBI connections in the guide about that.
i guess i was just thinking about making myself more aware of the
number of connections.
On Aug 18, 2005, at 1
On 18 Aug 2005, at 18:18, Jonathan Vanasco wrote:
Instead of connecting to the DB and having DBI cache the handle
after-the-fork, would it make sense to subclass Apache::DBI, have
the parent process create a defined number of connections, and then
use some sort of roundrobin/checkout to si
Instead of connecting to the DB and having DBI cache the handle
after-the-fork, would it make sense to subclass Apache::DBI, have the
parent process create a defined number of connections, and then use
some sort of roundrobin/checkout to sign out a handle during a request?
You're asking "why?"
On 5/4/05, Philip M. Gollucci <[EMAIL PROTECTED]> wrote:
> Kevin Old wrote:
>
> >Hello everyone,
> >
> >I'm getting the following errors when uncommenting this Apache::DBI
> >statement, on a site the works flawlessly when I comment out this
> >Apache::DBI connection:
> >
> ># From http://kold.home
Kevin Old wrote:
Hello everyone,
I'm getting the following errors when uncommenting this Apache::DBI
statement, on a site the works flawlessly when I comment out this
Apache::DBI connection:
# From http://kold.homelinux.com/startup.pl.txt
#Apache::DBI->connect_on_init
# ('dbi:ODBC:ivr',
# 'uavra
Hello everyone,
I'm getting the following errors when uncommenting this Apache::DBI
statement, on a site the works flawlessly when I comment out this
Apache::DBI connection:
# From http://kold.homelinux.com/startup.pl.txt
#Apache::DBI->connect_on_init
# ('dbi:ODBC:ivr',
# 'uavracks','uavracks'
27 matches
Mail list logo
