Let me just try it out since I've got a test case, and if need be I'll file the ticket & commit.
Kris On Fri, Nov 13, 2009 at 10:45 AM, Derek Chen-Becker <dchenbec...@gmail.com> wrote: > Looking at 81f1715f671e8b5ee4f6d3ce242cc9da272611d1, maybe the RequestVar > needs to be changed to an UnboundRequestVar. It's not clear from the > scaladocs on UnboundRequestVar, though, that this is the intent. It looks > like those scaladocs were just copied and pasted from RequestVar. If this > sounds like the right change to make I can fix RequestVarEM and update the > scaladocs for UnboundRequestVar. > > Derek > > On Fri, Nov 13, 2009 at 11:24 AM, Kris Nuttycombe > <kris.nuttyco...@gmail.com> wrote: >> >> On Thu, Nov 12, 2009 at 5:57 PM, David Pollak >> <feeder.of.the.be...@gmail.com> wrote: >> > Kris, >> > >> > There was a bunch of changes in the net.liftweb.mapper.DB code for >> > transaction management, but I don't think that would impact JPA. >> > >> > Also, in M7, there were changes in how RequestVars are handled during >> > Ajax >> > requests... basically, state is snapshotted when the Ajax request is >> > created >> > and then that snapshot state is restored during the servicing of the >> > Ajax >> > request. If the RequestVarEM stuff is being snapshotted, that could >> > cause >> > issues. >> > >> > Thanks, >> > >> > David >> >> That sounds like it could very likely be the culprit, but I'm going to >> have to dig a bit more to know for certain. >> >> the RequestVarEM trait uses the following RequestVar: >> >> object emVar extends RequestVar[EntityManager](openEM()) { >> this.registerGlobalCleanupFunc(ignore => closeEM(this.is)) >> >> override def __nameSalt = net.liftweb.util.Helpers.randomString(10) >> } >> >> openEM() is supplied in my case by JndiEMF. If this would not be >> called during handling of an AJAX request, that's definitely the >> issue. >> >> This brings to mind an issue I'd worried about a long time ago, back >> when I had my own implementation of a JNDI resource acquisition trait >> for persistence. We can tie into the cleanup phase of the RequestVar's >> lifecycle with a cleanup func, but if the RequestVar is going to be >> persisted across actual HTTP requests in the AJAX case, we will also >> need additional lifecycle hooks. I'm actually kind of concerned about >> this decision; it seems like it could really complicate usage of >> RequestVar in cases where the container has additional stuff it does >> related to the lifecycle of the HTTP request (like JTA). >> >> Maybe there should be a separate AnyVar subclass that is intended for >> this sort of persist-for-ajax situation? >> >> Kris >> >> > >> > On Thu, Nov 12, 2009 at 4:49 PM, Kris Nuttycombe >> > <kris.nuttyco...@gmail.com> >> > wrote: >> >> >> >> Hi, all (Derek! :), >> >> >> >> Have there been significant changes in how transactions are handled by >> >> lift-jpa since M6? Due to the rearrangement of the repository, I'm >> >> having a hard time figuring out if the code has changed. >> >> >> >> I have a repeatable issue that shows up when changing between M6 and >> >> SNAPSHOT wherein I now get >> >> javax.persistence.TransactionRequiredExceptions when doing a merge >> >> using a JndiEMF with RequestVarEM in an AJAX callback. >> >> >> >> Has anything major changed in this timeframe? >> >> >> >> Kris >> >> >> >> >> > >> > >> > >> > -- >> > 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 liftweb@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 -~----------~----~----~----~------~----~------~--~---