Now, now lets not get testi ;-)
On 09/09/2008, at 9:34 PM, Viktor Klang wrote:
>
>
> On Tue, Sep 9, 2008 at 10:09 AM, Oliver <[EMAIL PROTECTED]> wrote:
> Actually, is this the essence of the cookie. Why has the object been
> detached in the example Kris gives - is there something wrong with
> RequestVar lifecycle?
>
> Actually, just add a simple debug-print when the session is created
> and when it's closed. And if it prints that it is closed _before_
> the execption is raised then there certainly is a problem with the
> requestvar lifecycle.
>
> Ideally the entitymanager should be managed outside the scope of
> request-vars, since the order of request-var destruction isn't
> given, which means that if the cleanup is done in the "wrong" order,
> the Session is closed before referenced objects are cleaned up,
> which introduces the possibility for weirdness.
>
> Cheers,
> Viktor
>
>
>
> On Tue, Sep 9, 2008 at 5:27 PM, Viktor Klang
> <[EMAIL PROTECTED]> wrote:
> Hello Kris,
>
> this is a quite common problem in the world of JPA and object
> references.
> I'm not going to bore people out by talking about object lifecycles,
> but here's the essence of the cookie:
>
> When a JPA Session is created, it is bound to some context (wether
> it be the currently running thread, a session-bean, an HTTPSession
> or a RequestVar)
> Any PEs ( Persistent Entities) loaded through it will be associated
> with that particular Session instance, however, JPA tries to proxy
> alot of objects and collections
> to avoid having to load whole object graphs into memory when they
> haven't been requested.
> Your problem arises when you try to access a proxy outside the scope
> of the Session ( Google for Detached + JPA for more info on when an
> object is outside the scope of a Session)
>
>
> What I usually do if I want to hang onto references (Detached) to
> JPA-managed objects is that I create my own proxy around it that
> does something like the following:
>
> if(!currentSession.contains(myObject))
> currentSession.refresh(myObject); //Reattaches the object to the
> session
>
> return myObject;
>
> However, this is also a pretty dangerous strategy, so you'll have to
> know what you're doing here. (First-commit-wins, Last-commit-wins,
> partial overwrites, lost updates... the list goes on)
>
> Hope someone finds this informative.
>
> Cheers,
> Viktor
>
>
> On Mon, Sep 8, 2008 at 11:31 PM, Kris Nuttycombe <[EMAIL PROTECTED]
> > wrote:
>
> I've been following the advancement of the JPA/Lift tutorial with
> great interest, and have managed to get my app working, but I'm now
> struggling with a problem that occurs whenever I try to retrieve a
> collection that is mapped as a lazy association:
>
> Exception occured while processing /orders/list
>
> Message: org.hibernate.LazyInitializationException: failed to lazily
> initialize a collection of role:
> com.gaiam.gcsi.entities.subscription.Order.subscriptions, no session
> or session was closed
>
> org
> .hibernate
> .collection
> .AbstractPersistentCollection
> .throwLazyInitializationException(AbstractPersistentCollection.java:
> 358)
>
> org
> .hibernate
> .collection
> .AbstractPersistentCollection
> .throwLazyInitializationExceptionIfNotConnected
> (AbstractPersistentCollection.java:350)
>
> org
> .hibernate
> .collection
> .AbstractPersistentCollection
> .readSize(AbstractPersistentCollection.java:97)
>
> org.hibernate.collection.PersistentBag.size(PersistentBag.java:225)
> com.gaiam.gcsi.snippet.Orders$$anonfun$list
> $1.apply(Orders.scala:21)
> com.gaiam.gcsi.snippet.Orders$$anonfun$list
> $1.apply(Orders.scala:18)
> scala.Seq$class.flatMap(Seq.scala:267)
> com.gaiam.gcsi.model.EM$$anon$1.flatMap(EM.scala:11)
> com.gaiam.gcsi.snippet.Orders.list(Orders.scala:18)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
>
> I took the simplest-possible route of encapsulating the EntityManager
> in a RequestVar per Derek's suggestion as such:
>
> object EM {
> def entityManager() = (new
> InitialContext()).lookup("java:comp/env/persistence/
> em").asInstanceOf[EntityManager]
> }
>
> class Orders {
> object em extends RequestVar(entityManager())
>
> def list(xhtml: NodeSeq) : NodeSeq = {
> val orders = em.createQuery("from
> Order").getResultList().asInstanceOf[java.util.List[Order]]
> orders.flatMap(order =>
> bind("order", xhtml,
> "id" --> Text(order.getId().toString),
> "count" --> Text(order.getSubscriptions().size().toString)))
> }
> }
>
> The issue appears to be that the transaction that the the query ran in
> is no longer active by the time of the call to
> order.getSubscriptions(). Has anyone else been using JTA and
> encountered this? I'm running the latest stable Glassfish (2.1 UR2)
> and using Hibernate for the persistence layer.
>
> Thanks,
>
> Kris
>
>
>
>
>
> --
> Viktor Klang
> Rogue Software Architect
>
>
>
>
>
>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>
> >
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
