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