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.

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.  This also works around
the above mentioned deadlock issue.  The temporary expansion can be disabled
by override protected def allowTemporaryPoolExpansion = false

Thanks,

David

PS -- We're getting close to M8.  Please test the current SNAPSHOT and
report any anomalies.


-- 
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

--

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