[Lift] Re: Changes to transaction handling since M6?
That's really odd. As far as I know the only thing JPA related that might have changed is for the JPA Demo site (pom Hibernate version change). The transaction handling code is all in ScalaJPA, which also hasn't changed. JndiEMF explicitly opens a transaction before it even retrieves the EM from JNDI, so I don't know how you could be getting that kind of error. If you could give me more details (on-list or privately) I'd like to figure out what's going on here. Derek On Thu, Nov 12, 2009 at 5:49 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
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
-~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
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
-~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
Hmmm is this now TransientRequestVar? It's private[http], but
could it be protected instead?
Kris
On Fri, Nov 13, 2009 at 11:22 AM, Kris Nuttycombe
kris.nuttyco...@gmail.com wrote:
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
-~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
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
-~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
Looks like it. Probably private[liftweb] would work, too. In any case, the
scaladocs need to be updated to reflect what it's for.
On Fri, Nov 13, 2009 at 12:26 PM, Kris Nuttycombe kris.nuttyco...@gmail.com
wrote:
Hmmm is this now TransientRequestVar? It's private[http], but
could it be protected instead?
Kris
On Fri, Nov 13, 2009 at 11:22 AM, Kris Nuttycombe
kris.nuttyco...@gmail.com wrote:
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
-~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
On Fri, Nov 13, 2009 at 11:46 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: Looks like it. Probably private[liftweb] would work, too. In any case, the scaladocs need to be updated to reflect what it's for. On Fri, Nov 13, 2009 at 12:26 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hmmm is this now TransientRequestVar? It's private[http], but could it be protected instead? Kris David, do you have an opinion? Is there any reason to keep this private to lift, or is it something that 3rd-party libraries could make use of (as in this case?) Kris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
On Fri, Nov 13, 2009 at 12:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Fri, Nov 13, 2009 at 11:46 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: Looks like it. Probably private[liftweb] would work, too. In any case, the scaladocs need to be updated to reflect what it's for. On Fri, Nov 13, 2009 at 12:26 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hmmm is this now TransientRequestVar? It's private[http], but could it be protected instead? Kris David, do you have an opinion? Is there any reason to keep this private to lift, or is it something that 3rd-party libraries could make use of (as in this case?) I wanted to keep it as narrow as possible while we saw how it worked and got better naming. Making it private[liftweb] is fine and we'll open it up later. 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 -~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
On Fri, Nov 13, 2009 at 3:42 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Nov 13, 2009 at 12:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Fri, Nov 13, 2009 at 11:46 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: Looks like it. Probably private[liftweb] would work, too. In any case, the scaladocs need to be updated to reflect what it's for. On Fri, Nov 13, 2009 at 12:26 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hmmm is this now TransientRequestVar? It's private[http], but could it be protected instead? Kris David, do you have an opinion? Is there any reason to keep this private to lift, or is it something that 3rd-party libraries could make use of (as in this case?) I wanted to keep it as narrow as possible while we saw how it worked and got better naming. Making it private[liftweb] is fine and we'll open it up later. Okay, done and on ReviewBoard. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
FWIW regarding naming, since the change I've started to mentally rename RequestVar to PageVar. I don't think it's reasonable to rename the actual class, since everybody uses it, but I found it was a helpful mnemonic to remember what scope it has. -Ross On Nov 13, 2009, at 6:00 PM, Kris Nuttycombe wrote: On Fri, Nov 13, 2009 at 3:42 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Nov 13, 2009 at 12:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Fri, Nov 13, 2009 at 11:46 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: Looks like it. Probably private[liftweb] would work, too. In any case, the scaladocs need to be updated to reflect what it's for. On Fri, Nov 13, 2009 at 12:26 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hmmm is this now TransientRequestVar? It's private[http], but could it be protected instead? Kris David, do you have an opinion? Is there any reason to keep this private to lift, or is it something that 3rd-party libraries could make use of (as in this case?) I wanted to keep it as narrow as possible while we saw how it worked and got better naming. Making it private[liftweb] is fine and we'll open it up later. Okay, done and on ReviewBoard. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Changes to transaction handling since M6?
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 On Thu, Nov 12, 2009 at 4:49 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: 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 -~--~~~~--~~--~--~---
