Mailing List Archive: Catalyst: Users

Connect DBIx::Class model on startup?

Index | Next | Previous | View Threaded

dluke at geeklair

Feb 21, 2012, 10:30 AM

Post #1 of 13 (479 views)
Permalink

Connect DBIx::Class model on startup?

Is there a canonical (or recommended) way to have my new fastcgi processes' model(s) connect to their databases on startup (instead of during the first request?)

I'd like to be able to avoid the extra delay on the first request each fastcgi process has while it's connecting to the DB. I think it probably belongs in my Catalyst::Model::DBIC::Schema class (maybe after BUILD ?)

Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.

Thanks.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

c.kras at pcc-online

Feb 24, 2012, 1:31 PM

Post #2 of 13 (449 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

You might want to take a look at DBD::Gofer. It supports a connection
pool for reusing persistent connections.

Have a look at
https://metacpan.org/module/DBD::Gofer#Connection-Pooling-and-Throttling

--
Christiaan Kras
http://blog.htbaa.com

Op 21-02-12 19:30, Daniel J. Luke schreef:
> Is there a canonical (or recommended) way to have my new fastcgi processes' model(s) connect to their databases on startup (instead of during the first request?)
>
> I'd like to be able to avoid the extra delay on the first request each fastcgi process has while it's connecting to the DB. I think it probably belongs in my Catalyst::Model::DBIC::Schema class (maybe after BUILD ?)
>
> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>
> Thanks.
> --
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke [at] geeklair ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> | Opinions expressed are mine and do not necessarily |
> | reflect the opinions of my employer. |
> +========================================================+
>
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Feb 24, 2012, 1:59 PM

Post #3 of 13 (452 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

"AutoCommit only. Transactions aren't supported."

That makes it a non-starter for me, thanks for the pointer, though.

On Feb 24, 2012, at 4:31 PM, Christiaan Kras wrote:
>
> You might want to take a look at DBD::Gofer. It supports a connection pool for reusing persistent connections.
>
> Have a look at https://metacpan.org/module/DBD::Gofer#Connection-Pooling-and-Throttling
>
> Op 21-02-12 19:30, Daniel J. Luke schreef:
>> Is there a canonical (or recommended) way to have my new fastcgi processes' model(s) connect to their databases on startup (instead of during the first request?)
>>
>> I'd like to be able to avoid the extra delay on the first request each fastcgi process has while it's connecting to the DB. I think it probably belongs in my Catalyst::Model::DBIC::Schema class (maybe after BUILD ?)
>>
>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>
>> Thanks.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

Feb 25, 2012, 12:39 AM

Post #4 of 13 (451 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

> Op 21-02-12 19:30, Daniel J. Luke schreef:
>> Is there a canonical (or recommended) way to have my new fastcgi processes' model(s) connect to their databases on startup (instead of during the first request?)
>>
>> I'd like to be able to avoid the extra delay on the first request each fastcgi process has while it's connecting to the DB. I think it probably belongs in my Catalyst::Model::DBIC::Schema class (maybe after BUILD ?)
>>
>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.

It's not totally obvious as you can't do this at process startup (as you then fork!), so it has to be done in the FCGI process manager really (which does the forking)�

You can subclass FCGI::ProcManager and implement:

sub handling_init {
my $self = shift;
$self->next::method(@_);
MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
}

You can then pass your fastcgi.pl script the option to use your custom process manager, and you're sorted.

Cheers
t0m
_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Feb 25, 2012, 7:00 AM

Post #5 of 13 (451 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>
> It's not totally obvious as you can't do this at process startup (as you then fork!),

Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).

> so it has to be done in the FCGI process manager really (which does the forking)�
>
> You can subclass FCGI::ProcManager and implement:
>
> sub handling_init {
> my $self = shift;
> $self->next::method(@_);
> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
> }
>
> You can then pass your fastcgi.pl script the option to use your custom process manager, and you're sorted.

Perfect, thanks!

--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Mar 2, 2012, 12:44 PM

Post #6 of 13 (442 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Feb 25, 2012, at 10:00 AM, Daniel J. Luke wrote:
> On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>
>> It's not totally obvious as you can't do this at process startup (as you then fork!),
>
> Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).
>
>> so it has to be done in the FCGI process manager really (which does the forking)�
>>
>> You can subclass FCGI::ProcManager and implement:
>>
>> sub handling_init {
>> my $self = shift;
>> $self->next::method(@_);
>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.

Maybe I'm being thick, but where does that instance of MyApp come from? I don't see it being passed into FCGI::ProcManager

>> }
>>
>> You can then pass your fastcgi.pl script the option to use your custom process manager, and you're sorted.
>
> Perfect, thanks!

--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

Mar 4, 2012, 6:56 AM

Post #7 of 13 (440 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On 2 Mar 2012, at 20:44, Daniel J. Luke wrote:

> On Feb 25, 2012, at 10:00 AM, Daniel J. Luke wrote:
>> On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>>
>>> It's not totally obvious as you can't do this at process startup (as you then fork!),
>>
>> Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).
>>
>>> so it has to be done in the FCGI process manager really (which does the forking)�
>>>
>>> You can subclass FCGI::ProcManager and implement:
>>>
>>> sub handling_init {
>>> my $self = shift;
>>> $self->next::method(@_);
>>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
>
> Maybe I'm being thick, but where does that instance of MyApp come from? I don't see it being passed into FCGI::ProcManager

What instance of MyApp?

There is no instance?

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Mar 4, 2012, 6:30 PM

Post #8 of 13 (438 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Mar 4, 2012, at 9:56 AM, Tomas Doran wrote:
> On 2 Mar 2012, at 20:44, Daniel J. Luke wrote:
>> On Feb 25, 2012, at 10:00 AM, Daniel J. Luke wrote:
>>> On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>>>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>>>
>>>> It's not totally obvious as you can't do this at process startup (as you then fork!),
>>>
>>> Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).
>>>
>>>> so it has to be done in the FCGI process manager really (which does the forking)�
>>>>
>>>> You can subclass FCGI::ProcManager and implement:
>>>>
>>>> sub handling_init {
>>>> my $self = shift;
>>>> $self->next::method(@_);
>>>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
>>
>> Maybe I'm being thick, but where does that instance of MyApp come from? I don't see it being passed into FCGI::ProcManager
>
> What instance of MyApp?

the one that I'm going to call ->model() on in order to pre-connect to my DB?

> There is no instance?

Then there's some magic that I'm missing? If I take your code literally, I'm going to get a 'cannot use a string as a hash ref' error.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

will.trillich at serensoft

Mar 4, 2012, 8:23 PM

Post #9 of 13 (439 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Sun, Mar 4, 2012 at 8:30 PM, Daniel J. Luke <dluke [at] geeklair> wrote:

> >>>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB
> connection that's working straight after forking but before starting to
> handle requests.
> >>
> >> Maybe I'm being thick, but where does that instance of MyApp come from?
> I don't see it being passed into FCGI::ProcManager
> >
> > What instance of MyApp?
>

MyApp->method() is a direct reference to the original package, not to an
instance.

my $myapp = MyApp->instantiate() would be an instance, if you had such a
method to call.

use MyApp;
MyApp->something();

MyApp has been included as a library, so now you can call it appropriately.
There's *no instance* in this case...

> the one that I'm going to call ->model() on in order to pre-connect to my
> DB?
>
> > There is no instance?
>
>
> Then there's some magic that I'm missing? If I take your code literally,
> I'm going to get a 'cannot use a string as a hash ref' error.
>
> --
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke [at] geeklair ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> | Opinions expressed are mine and do not necessarily |
> | reflect the opinions of my employer. |
> +========================================================+
>
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

--
"We act as though comfort and luxury were the chief requirements of life,
when all that we need to make us happy is something to be enthusiastic
about." -- Albert Einstein

bobtfish at bobtfish

Mar 5, 2012, 12:15 AM

Post #10 of 13 (437 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On 5 Mar 2012, at 02:30, Daniel J. Luke wrote:

> On Mar 4, 2012, at 9:56 AM, Tomas Doran wrote:
>> On 2 Mar 2012, at 20:44, Daniel J. Luke wrote:
>>> On Feb 25, 2012, at 10:00 AM, Daniel J. Luke wrote:
>>>> On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>>>>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>>>>
>>>>> It's not totally obvious as you can't do this at process startup (as you then fork!),
>>>>
>>>> Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).
>>>>
>>>>> so it has to be done in the FCGI process manager really (which does the forking)�
>>>>>
>>>>> You can subclass FCGI::ProcManager and implement:
>>>>>
>>>>> sub handling_init {
>>>>> my $self = shift;
>>>>> $self->next::method(@_);
>>>>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
>>>
>>> Maybe I'm being thick, but where does that instance of MyApp come from? I don't see it being passed into FCGI::ProcManager
>>
>> What instance of MyApp?
>
> the one that I'm going to call ->model() on in order to pre-connect to my DB?

Erm? Where did I suggest that?

(I didn't - I suggested calling a class method, which ->model is�)

>
>> There is no instance?
>
>
> Then there's some magic that I'm missing? If I take your code literally, I'm going to get a 'cannot use a string as a hash ref' error.

Did you try this already?

Unless you've specifically done something to break how things normally work, then it'll work fine.

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Mar 5, 2012, 7:01 AM

Post #11 of 13 (442 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Mar 5, 2012, at 3:15 AM, Tomas Doran wrote:
> On 5 Mar 2012, at 02:30, Daniel J. Luke wrote:
>> On Mar 4, 2012, at 9:56 AM, Tomas Doran wrote:
>>> On 2 Mar 2012, at 20:44, Daniel J. Luke wrote:
>>>> On Feb 25, 2012, at 10:00 AM, Daniel J. Luke wrote:
>>>>> On Feb 25, 2012, at 3:39 AM, Tomas Doran wrote:
>>>>>>>> Or maybe there's a reason why there's not an obvious hook and someone can point me to the pitfalls I'm not seeing.
>>>>>>
>>>>>> It's not totally obvious as you can't do this at process startup (as you then fork!),
>>>>>
>>>>> Yeah, I just realized that that was going to be an issue when I went to attempt this (late yesterday).
>>>>>
>>>>>> so it has to be done in the FCGI process manager really (which does the forking)�
>>>>>>
>>>>>> You can subclass FCGI::ProcManager and implement:
>>>>>>
>>>>>> sub handling_init {
>>>>>> my $self = shift;
>>>>>> $self->next::method(@_);
>>>>>> MyApp->model('DB')->schema->dbh->ping; # Check we have a DB connection that's working straight after forking but before starting to handle requests.
>>>>
>>>> Maybe I'm being thick, but where does that instance of MyApp come from? I don't see it being passed into FCGI::ProcManager
>>>
>>> What instance of MyApp?
>>
>> the one that I'm going to call ->model() on in order to pre-connect to my DB?
>
> Erm? Where did I suggest that?

you didn't, when it didn't work, I assumed that there was just a missing sigil in what you pasted (that's why I figured I was being thick ;-) ).

> (I didn't - I suggested calling a class method, which ->model is�)
>
>>> There is no instance?
>>
>> Then there's some magic that I'm missing? If I take your code literally, I'm going to get a 'cannot use a string as a hash ref' error.
>
> Did you try this already?

yes:
FastCGI: manager (pid 18350): server (pid 19242) started
Can't use string ("MyApp") as a HASH ref while "strict refs" in use at /path/to/lib/vendor_perl/5.12.2/Class/Accessor/Fast.pm line 10.

> Unless you've specifically done something to break how things normally work, then it'll work fine.

I don't think I've done anything unusual.

perl 5.12.2
Class::Accessor::Fast 0.34
Catalyst 5.80031
--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

Mar 5, 2012, 8:33 AM

Post #12 of 13 (428 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On 5 Mar 2012, at 15:01, Daniel J. Luke wrote:
> yes:
> FastCGI: manager (pid 18350): server (pid 19242) started
> Can't use string ("MyApp") as a HASH ref while "strict refs" in use at /path/to/lib/vendor_perl/5.12.2/Class/Accessor/Fast.pm line 10.
>

Can we get an actual backtrace here? -MDevel::SimpleTrace or something?

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dluke at geeklair

Mar 6, 2012, 10:25 AM

Post #13 of 13 (437 views)
Permalink

Re: Connect DBIx::Class model on startup? [In reply to]

On Mar 5, 2012, at 10:01 AM, Daniel J. Luke wrote:
>> Unless you've specifically done something to break how things normally work, then it'll work fine.
>
> I don't think I've done anything unusual.

I guess I was wrong ;-)

A little time in the perl debugger and I found where my ACCEPT_CONTEXT method was actually causing the error I was seeing.

Everything works great now.

Thanks for the help (and sorry for the extra noise).

--
Daniel J. Luke
+========================================================+
| *---------------- dluke [at] geeklair ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads