David Pollak <feeder.of.the.be...@gmail.com> writes:

> Folks,
>
> A month or so ago, I made the DB.buildLoanWrapper lazy.  While it provided a
> request-duration transaction, it did not actually pull the JDBC connection
> from the pool until the first request for the JDBC connection.  This led to
> some problems.  Basically:
>
> object MySnippet {
>   def render = synchronized {
>     ... do a query in here
>   }
> }
>
> If some threads acquired the JDBC connection before invoking the snippet
> while others acquired the JDBC connection inside the synchronized (note it's
> an object) render method, there could be a deadlock caused by JDBC pool
> starvation.  This is unexpected and not likely to manifest unless you've got
> a non-trivial number of threads servicing requests.
>
> To avoid this unexpected situation, I returned DB.buildLoanWrapper to being
> eager, but you (and by you, I mean Jeppe), can also call
> DB.buildLoanWrapper(false) which will have the newer, lazy behavior.

Thanks for the direct attention :-) I can see the problem, but just so
I understand this completely: Can we agree that,

1) The above pattern (global synchronized render method) is a rather bad
pattern, scalability wise?

2) If there are no such methods (in user code), lazy connection acquiring is 
fine?

The question remains of course, if there are more such accidents waiting
to happen? I always try to avoid using synchronize in application code
(where possible :-) but I realize that Lift as a framework has to be
somewhat more low level.

> Additionally, the default thread pool manager in Lift (ProtoDBVendor) will
> allow temporary pool expansion.  If there are no connections available after
> waiting 50ms, the pool will be temporarily expanded.

Is there a limit to the expansion? (Before we know we've implemented
c3p0 :-)

[...]

/Jeppe

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.


Reply via email to