On 11/07/2011, at 5:53 PM, Mark Struberg wrote: > 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.
This will still work fine as long as the container does not actually try and actually serialize the session. Not everyone uses HA clustering. > > * 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. From the conversion scope bit of the spec: "The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests." If you were seeing behaviour to the contrary then this is a bug. > > * EntityManager#lock must not get used. > > * native Queries might return wrong results. > > * non-trivial Queries might return wrong results. This is the expected behaviour when using a MANUAL flush mode. > > * 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... I don't see how it is possible to serialize an EntityManager that is enlisted in a transaction anyway, and as the locks only last till the end of the transaction I don't see how Serialization affects locking. > > 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. > Not really sure what you mean here, arn't you just describing something similar to a standard transaction scoped em? Stuart > 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 <[email protected]> wrote: > >> From: Emmanuel Bernard <[email protected]> >> Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension >> To: "Mark Struberg" <[email protected]> >> Cc: "John D. Ament" <[email protected]>, "[email protected]" >> <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>> >>> From: John D. Ament <[email protected]> >>> Subject: Re: [seam-dev] [seam-persistence] >> ManagedPersistenceContextExtension >>> To: "Mark Struberg" <[email protected]> >>> Cc: "Stuart Douglas" <[email protected]>, >> [email protected] >>> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>> >>> >>> >>>> From: Stuart Douglas <[email protected]> >>> >>>> Subject: Re: [seam-dev] [seam-persistence] >> ManagedPersistenceContextExtension >>> >>>> To: "Mark Struberg" <[email protected]> >>> >>>> Cc: [email protected] >>> >>>> 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 >>> >>>>> [email protected] >>> >>>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>>> >>> >>>> >>> >>> _______________________________________________ >>> >>> seam-dev mailing list >>> >>> [email protected] >>> >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> seam-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
