I'm not sure about Hibernate, but OpenJPA and Eclipselink both store _loaded and _dirty bitfields in detached entities and this info will also get serialized along the line.

Ok txs. This means Hibernate must load all properties of an entity in a very eager way. Even ElementCollections and blobs, right? Otherwise you cannot distinguish between *) field is null because the blob didn't get loaded yet (_loaded==false) *) field is null because it got set to null to clear it (_loaded==true, _dirty==true)

The _dirty is not that important (only can help to improve performance), but it would be fine if the JPA spec could introduce a @Loaded private BitField _loaded;

Hi Emmanuel! My point is: Some features of seam-persistence are more a seam-hibernate (as upgrade path from Seam2 this makes perfect sense I guess) than a general JPA thingy. They only work with Hibernate and cannot be generalized to other JPA providers! And even if you use Hibernate, then there are a few restrictions which should get added to the documentation. I'll try to sum up: If you use a scope bigger than @RequestScoped on the EnitityManagerProducer then: * This only works with Hibernate and FlushMode.MANUAL. No other JPA provider will do since the EntityManager impls are usually _not_ Serializable. * The problem is that most queries will be performed inside a @Transactional bracelet thus they might have an open transaction. In this case there is no temp-transaction which could be rollbacked. Thus the 'baby non auto-flush' doesn't work out I fear. * Also in JPA managed entities must not get accessed from multiple threads in parallel. All scopes longer than @RequestScoped are subject of being hit by parallel AJAX calls or requests from multiple windows. It's only a matter of load to get this situation. I was easily able to reproduce such scenarios with JMeter [1] with 50 parallel threads. * EntityManager#lock must not get used. * native Queries might return wrong results. * non-trivial Queries might return wrong results. * no select for update allowed. But I agree completely with you that a Serializable EntityManager would be a BIG benefit. I frankly fear this is only possible by dropping all the pessimistic locking stuff and not doing so much things automatically. There is a JPA-like project called eBean [2] which does exactly that. But it's not a JPA provider exactly because of that... Imo the easiest way to cope with that situation is to emulate the transactional stuff of EJB with an extended EntityManager. Opening the transaction once the outer @Transactional gets entered, and committing/rollback + closing the EntityManager as soon as you leave the outermost @Transactional method. This will detach all entities immediately, so they can be transfered, used, whatever... One just needs to em.merge them to get them stored later. I'm not sure about Hibernate, but OpenJPA and Eclipselink both store _loaded and _dirty bitfields in detached entities and this info will also get serialized along the line. LieGrue, strub [1] http://jakarta.apache.org/jmeter/ [2] http://www.avaje.org/ --- On Mon, 7/11/11, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > From: Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: "John D. Ament" <john.d.ament(a)gmail.com&gt;, &quot;seam-dev(a)lists.jboss.org&quot; <seam-dev(a)lists.jboss.org&gt; > Date: Monday, July 11, 2011, 12:08 AM > Hibernate has the notion of > FlushMode.MANUAL to prevent operations from being pushed to > the DB even upon queries. JPA has a baby version of that > with extended persistence contexts behaving outside > transactions. > > Yes some methods like lock are not allowed when the em is > expected to be passivated. But that's not a reason to > disable a useful feature (passivation) altogether. > Passivation is sometimes not possible but that far from > your statement "This is never _never_ NEVER true. The > EntityManager is not Serializable!". > > Emmanuel > > PS: There are more efficient ways to passivate an > entityManager than serializing it with some help from the > persistence provider. I don't remember if we ever finished > this work. >> > > > On 11 juil. 2011, at 01:44, Mark Struberg <struberg(a)yahoo.de&gt; > wrote: > >> There are a few problems which can happen: >> >> a.) EmtityManager#lock(java.lang.Object o, > javax.persistence.LockModeType lockModeType); and others > with LockType#PESSIMISTIC_* >> >> b.) Consider you have an Entity dirty or a fresh one > created with em.persist(). And now you do a non-trivial > query. In order to guarantee that this new/modified entity > gets evaluated properly, JPA _explicitly_ allows the > EntityManager to write those values into the database. > Voila, you have your open transaction! Not too many people > are aware of that but yes, querying from the database can > lead to a SQL INSERT or SQL UPDATE into the database! Of > course, you better _not_ commit those changes immediately > ;) >> >> >> LieGrue, >> strub >> >> >> >> --- On Sun, 7/10/11, John D. Ament <john.d.ament(a)gmail.com&gt; > wrote: >> >> From: John D. Ament <john.d.ament(a)gmail.com&gt; >> Subject: Re: [seam-dev] [seam-persistence] > ManagedPersistenceContextExtension >> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >> Cc: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt;, > seam-dev(a)lists.jboss.org >> Date: Sunday, July 10, 2011, 11:29 PM >> >> But is the select for update done inside the > entitymanager object or a query instance? I don't > think EntityManager.find(Class,Id) does any type of hold on > the object found. >> >> John >> >> >> On Sun, Jul 10, 2011 at 7:15 PM, Mark Struberg <struberg(a)yahoo.de&gt; > wrote: >> >> Stu, whenever you do a "select for update" or any > manual locking, you will end up with an EntityManager which > cannot be transfered to another node. Even if hibernate > marks it's EntityManager Serializable, it just isn't if I > didn't miss something! >> >> >> >> >> LieGrue, >> >> strub >> >> >> >> --- On Sun, 7/10/11, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; > wrote: >> >> >> >>> From: Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; >> >>> Subject: Re: [seam-dev] [seam-persistence] > ManagedPersistenceContextExtension >> >>> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >> >>> Cc: seam-dev(a)lists.jboss.org >> >>> Date: Sunday, July 10, 2011, 11:07 PM >> >>> >> >>> On 11/07/2011, at 4:07 AM, Mark Struberg wrote: >> >>> >> >>>> Hi folks! >> >>>> >> >>>> While reviewing an OWB bug report, 2 questions > came >> >>> up: >> >>>> >> >>>> a.) EnvironmentUtils#isEEEnvironment() relies > on the >> >>> absence of 'javax.ejb.Stateless' to decide if a >> >>> PersitenceUnit gets injected or if you need to do > it >> >>> yourself. I think this is an unrelieable > assumption. E.g. >> >>> there are a few Extensions which emulate Stateless > Session >> >>> beans via a CDI Extension by morphing them into >> >>> @ApplicationScoped. >> >>> >> >>> This is not ideal, but I don't think there is > really any >> >>> portable way to detect if the environment is an > EE >> >>> environment or not. I was originally planning to > add a >> >>> method for configuring this, but it appears I did > not get >> >>> around to it. >> >>> >> >>>> >> >>>> b.) in >> >>> > ManagedPersistenceContextExtension#registerManagedPersistenceContext >> >>> you register the bean for the EntityManager as >> >>> passivationCapable. This is never _never_ NEVER > true. The >> >>> EntityManager is not Serializable! There is imo no > way to >> >>> have an EntityManager in a bean scoped other than >> >>> @RequestScoped or shorter (e.g. > @TransactionalScoped). Any >> >>> other trick is not working in a portable way. This > is mainly >> >>> caused by JPA still supporting pessimistic locking > (_real_ >> >>> locks in the database) as first class citizens. >> >>>> >> >>> >> >>> Without this it is not possible to have a > conversation >> >>> scoped entity manager. The hibernate EntityManager > is in >> >>> fact Serializable. Locks should not be a problem > as long as >> >>> you do not attempt to serialise the EM in the > middle of a >> >>> transaction. >> >>> >> >>> Stuart >> >>> >> >>> >> >>>> But I'd be happy if anyone could enlighten me > and tell >> >>> us how it works ;) >> >>>> >> >>>> LieGrue, >> >>>> strub >> >>>> > _______________________________________________ >> >>>> seam-dev mailing list >> >>>> seam-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/seam-dev >> >>> >> >>> >> >> _______________________________________________ >> >> seam-dev mailing list >> >> seam-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev