Weird request/transaction semantics

[Jeppe Nejsum Madsen]

Hi,

I posted this in another thread, but it may have been lost in the noise
(or no one cared :-)

Anyway, I have S.addAround(DB.buildLoanWrapper) in boot, which I assumed
would wrap each request with a transaction and thus use the same
connection for the duration of the request?

I've added some logging around newConnection/releaseConnection. I was a
little surprised to see that newConnection is called three times for
each request?

Is this intentional?

I can see that a connection is also being made even for static files
(such as css). This is not really a problem, but it would be nice to defer
acquiring a connection until needed....(since I now verify the
connection by doing an actual statement on the db server :-)

/Jeppe

[David Pollak]

There are a couple of things happening.

First, there are at least 2 distinct times when we initialize the S context during a request handling cycle:

• During the rewrite phase (if there's a session cookie)
• During the substantive processing phase
• If there's a cometactor on the page, S will be initialized twice per comet actor message processing (once during the testing of the message for ability to process and once during the message processing itself)

Lemme see what I can do about making it lazy... please open a ticket and I'll try to get to it today.

 

/Jeppe

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Jeppe Nejsum Madsen]

On Thu, Oct 22, 2009 at 6:12 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> There are a couple of things happening.
> First, there are at least 2 distinct times when we initialize the S context
> during a request handling cycle:
>
> During the rewrite phase (if there's a session cookie)
> During the substantive processing phase
> If there's a cometactor on the page, S will be initialized twice per comet
> actor message processing (once during the testing of the message for ability
> to process and once during the message processing itself)

One day, I'll have to dig into the request processing cycle :-)

But this does seem to be a potential problem lurking: If I need the
transaction to span the rewriting & processing phase this doesn't seem
possible atm (I haven't used cometactor yet).

I initially thought there were errors with how db connections are
acquired (I could get the same connection on two different requests),
but this turned out (I think) to be problems with the connection
manager: http://github.com/dpp/liftweb/issues#issue/124

> On Thu, Oct 22, 2009 at 8:54 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>
> wrote:
>>
>> Hi,
>>
>> I posted this in another thread, but it may have been lost in the noise
>> (or no one cared :-)
>>
>> Anyway, I have S.addAround(DB.buildLoanWrapper) in boot, which I assumed
>> would wrap each request with a transaction and thus use the same
>> connection for the duration of the request?
>>
>> I've added some logging around newConnection/releaseConnection. I was a
>> little surprised to see that newConnection is called three times for
>> each request?
>>
>> Is this intentional?
>>
>> I can see that a connection is also being made even for static files
>> (such as css). This is not really a problem, but it would be nice to defer
>> acquiring a connection until needed....(since I now verify the
>> connection by doing an actual statement on the db server :-)
>
> Lemme see what I can do about making it lazy... please open a ticket and
> I'll try to get to it today.

Done. http://github.com/dpp/liftweb/issues/#issue/129

/Jeppe

[David Pollak]

On Thu, Oct 22, 2009 at 12:06 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:

On Thu, Oct 22, 2009 at 6:12 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> There are a couple of things happening.
> First, there are at least 2 distinct times when we initialize the S context
> during a request handling cycle:
>
> During the rewrite phase (if there's a session cookie)
> During the substantive processing phase
> If there's a cometactor on the page, S will be initialized twice per comet
> actor message processing (once during the testing of the message for ability
> to process and once during the message processing itself)

One day, I'll have to dig into the request processing cycle :-)

But this does seem to be a potential problem lurking: If I need the
transaction to span the rewriting & processing phase this doesn't seem
possible atm

That's correct.  It would be terrifically difficult to do this.
 

(I haven't used cometactor yet).

This is define behavior.  The CometActor is never part of the HTTP request/response cycle.
 

I initially thought there were errors with how db connections are
acquired (I could get the same connection on two different requests),
but this turned out (I think) to be problems with the connection
manager: http://github.com/dpp/liftweb/issues#issue/124

> On Thu, Oct 22, 2009 at 8:54 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>
> wrote:
>>
>> Hi,
>>
>> I posted this in another thread, but it may have been lost in the noise
>> (or no one cared :-)
>>
>> Anyway, I have S.addAround(DB.buildLoanWrapper) in boot, which I assumed
>> would wrap each request with a transaction and thus use the same
>> connection for the duration of the request?
>>
>> I've added some logging around newConnection/releaseConnection. I was a
>> little surprised to see that newConnection is called three times for
>> each request?
>>
>> Is this intentional?
>>
>> I can see that a connection is also being made even for static files
>> (such as css). This is not really a problem, but it would be nice to defer
>> acquiring a connection until needed....(since I now verify the
>> connection by doing an actual statement on the db server :-)
>
> Lemme see what I can do about making it lazy... please open a ticket and
> I'll try to get to it today.

Done. http://github.com/dpp/liftweb/issues/#issue/129

/Jeppe