On May 19, 4:31 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> It should already. The closeEM method on both LocalEM and JndiEM checks to
> see if the transaction has been marked rollback only and should handle
> committing/rollback there. If it doesn't then it's a bug.
But we're talking about userTx==true. I mean this:
private def transaction(prog: =>Unit) {
val tx = EntityManager.getTransaction
try {
tx.begin
prog
tx.commit
} finally {
if(tx.isActive)
tx.rollback
}
}
...
def get = transaction {
val l = NatureLocationType.lookup(loc.id)
l.name = stringValues("name")
l.allowStreet = booleanValues("allowStreet")
l.allowHospital = booleanValues("allowHospital")
l.allowDoctor = booleanValues("allowDoctor")
l.allowEquipment = booleanValues("allowEquipment")
}
(continued below)
>
> Also, for your first question:
>
> (I take that to mean that setting entity properties does not require a
>
> > transaction? I thought that in JPA entities are generally monitored
> > for modifications? Is that a mistake?)
>
> In the context of a form processing function, the JPA entity is in a
> "detached" state at the point that its members are being updated because the
> session that it was loaded in (when the form rendered) is now closed. The
> transaction is only required when you perform the "merge" of the detached
> object into a new session to save the entity data. Whether or not the entity
> is actually monitored is an implementation detail, since the spec only says
> that when the entity is merged it should save data back to the database, but
> it doesn't specify how that is done. Any exceptions related to JPA should
> only occur during the flush, or possibly the merge if the JPA provider does
> an eager flush to the database. This is why I added the mergeAndFlush,
> persistAndFlush, and removeAndFlush methods, so that you would have a
> definite place to wrap in a try/catch. If you're doing multiple ops then
> you'll need to merge your entire block of merge,persist,remove and flush
> methods in a try/catch. Does that make sense? I know that sometimes the
> lifecycle of these things can take a few tries to wrap your head around, so
> if this isn't clear let me know and I'll try to rephrase.
I understand you, and that's what I thought too, but I got an
exception when I tried to merge a detached entity! If I could get an
entity in one request, close the EM, and in the next request just
modify it and merge it it would be great, but so far I haven't managed
to. If you can't think of any explanation offhand I'll try to
reproduce it in an isolated snippet.
Thanks!
>
> Derek
>
> On Tue, May 19, 2009 at 2:07 PM, ngug <naftoli...@gmail.com> wrote:
>
> > P.S. I wrote a method to handle the boilerplate of opening/closing/
> > checking whether to rollback transactions. Shouldn't ScalaJPA have
> > such a method? Or does it?
> > Thanks.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
