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