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.