>> OK, I got fed up with that synchronized block. OPENJPA-161 tracks >> the issue; I've got a patch that I'll submit once some more eyes >> look at
fine. I think from now on I can start to migrate my 60 CMP EB's ... I'll keep you updated ;-) Hans -------- Original-Nachricht -------- Datum: Thu, 22 Feb 2007 14:22:25 -0800 Von: "Patrick Linskey" <[EMAIL PROTECTED]> An: open-jpa-dev@incubator.apache.org CC: Betreff: RE: RE: Howto integrate JPA within EJB2.1 session beans? [architecture] > > Unfortunately, that means that we're using a synchronized > > block during the lookup. If it looks like EM lookup is a > > scalability issue for your app, do let us know -- it would > > be pretty straightforward to replace the synchronized block > > with a concurrent map. > > OK, I got fed up with that synchronized block. OPENJPA-161 tracks the > issue; I've got a patch that I'll submit once some more eyes look at it. > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > > -----Original Message----- > > From: Patrick Linskey [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 22, 2007 8:38 AM > > To: open-jpa-dev@incubator.apache.org > > Subject: RE: RE: Howto integrate JPA within EJB2.1 session > > beans? [architecture] > > > > > If I understand it correct, I "just" have to bind the EMF > > > onserver startup like. > > > > > > context.bind("my/jndi/name/for/emf",myEMFVariable); > > > > Yep. > > > > > //does the statement below again create a NEW EMF > > or ist this > > > //just a lookup in the jndi-tree? but why is it > > > called "Create" > > > //and not get? > > > EntityManagerFactory emf = OpenJPAPersistence > > > .createEntityManagerFactory( > > > "your/EMF/JNDI/location", (Context) null); > > > > It's just a lookup. I'm not sure why it's called 'create'. Anyone? > > > > > //why do I have to create a new > > broker/entitymanager this way? > > > //is this because I have to "synchronize" the SLSBs > > > transaction > > > //context with the newly created entitymanager? > > > > Yes -- our current OpenJPAPersistence EM lookup methods all create new > > EMs. The broker code will look up one associated with the current > > transaction, which is what you're looking for. > > > > Unfortunately, that means that we're using a synchronized block during > > the lookup. If it looks like EM lookup is a scalability issue for your > > app, do let us know -- it would be pretty straightforward to > > replace the > > synchronized block with a concurrent map. > > > > > So if understand that right I just would have to call > > > > > > PersistenceService.getEntitymanager(); > > > > > > in every SLSB method (NOT in ejbCreate) when needed? fine. > > > > Yep. > > > > > I really appreciate your help - it's quite complex to integrate > > > JPA into an existing Java2EE 1.4 AppServer environment.. *puh* > > > > Yes -- sorry about that. We should at least be creating > > better-designed > > helper methods in OpenJPA to help out with this. > > > > One alternative, of course, is to use Spring 2, which does a > > pretty good > > job of JPA bootstrapping. > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > > ______________________________________________________________ > > _________ > > Notice: This email message, together with any attachments, > > may contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, > > copyrighted and/or > > legally privileged, and is intended solely for the use of the > > individual > > or entity named in this message. If you are not the intended > > recipient, > > and have received this message in error, please immediately > > return this > > by email and then delete it. > > > > > -----Original Message----- > > > From: Hans Prueller [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, February 22, 2007 4:36 AM > > > To: open-jpa-dev@incubator.apache.org; > > > open-jpa-dev@incubator.apache.org > > > Subject: Re: RE: Howto integrate JPA within EJB2.1 session > > > beans? [architecture] > > > > > > Patrick, > > > > > > thank you for that tip. To be true, I was not aware of > > > lifecycle related problems between my SLSBs and JPA - thank > > > you for that hint. As I want to avoid working with > > > ThreadLocal (simply because I didn't work with ThreadLocals > > > yet) I would prefer the JNDI-EMF based approach. > > > > > > If I understand it correct, I "just" have to bind the EMF > > > onserver startup like. > > > > > > context.bind("my/jndi/name/for/emf",myEMFVariable); > > > > > > I would be interested what the code for the > > > PersistenceService class does: > > > > > > > > > //does the statement below again create a NEW EMF > > or ist this > > > //just a lookup in the jndi-tree? but why is it > > > called "Create" > > > //and not get? > > > EntityManagerFactory emf = OpenJPAPersistence > > > .createEntityManagerFactory( > > > "your/EMF/JNDI/location", (Context) null); > > > > > > //why do i have to cast the EMF to a brokerfactory now? I > > > //would guess the "broker" is something like a more abstract > > > //concept of entitymanager(factory)? > > > > > > //why do I have to create a new > > broker/entitymanager this way? > > > //is this because I have to "synchronize" the SLSBs > > > transaction > > > //context with the newly created entitymanager? > > > > > > BrokerFactory bf = OpenJPAPersistence.cast(emf); > > > Broker b = bf.newBroker( > > > bf.getConfiguration().getConnectionUserName(), > > > bf.getConfiguration().getConnectionPassword(), > > > true, // the broker is part of a JTA managed tx > > > bf.getConfiguration().getConnectionRetainModeConstant(), > > > true); // look for an existing Broker on the tx > > > > > > broker.setAutoDetach(AutoDetach.DETACH_CLOSE, true); > > > broker.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true); > > > broker.setDetachedNew(false); > > > > > > return OpenJPAPersistence.toEntityManager(b); > > > } > > > > > > So if understand that right I just would have to call > > > > > > PersistenceService.getEntitymanager(); > > > > > > in every SLSB method (NOT in ejbCreate) when needed? fine. I > > > really appreciate your help - it's quite complex to integrate > > > JPA into an existing Java2EE 1.4 AppServer environment.. *puh* > > > > > > regards > > > Hans > > > > > > -------- Original-Nachricht -------- > > > Datum: Wed, 21 Feb 2007 08:43:20 -0800 > > > Von: "Patrick Linskey" <[EMAIL PROTECTED]> > > > An: open-jpa-dev@incubator.apache.org > > > CC: > > > Betreff: RE: Howto integrate JPA within EJB2.1 session beans? > > > [architecture] > > > > > > > Another common technique is to get an EMF into JNDI, either > > > by using a > > > > startup hook or deploying OpenJPA as a JCA RAR. > > > > > > > > Are you looking to integrate OpenJPA with your current managed > > > > transaction? If so, I'd be careful about creating an EM in > > > ejbCreate(), > > > > as its lifecycle is related to the life of the SLSB, not to the > > > > transactional context (the SLSB might be pooled). So, I'd > > > just try to > > > > get the EMF into JNDI when the server starts (creating EMFs > > > is slow). > > > > Then, you could avoid having to use your own ThreadLocal > > > work by using > > > > the internal OpenJPA BrokerFactory APIs: > > > > > > > > public class PersistenceService { > > > > public static EntityManager getEntityManager() { > > > > EntityManagerFactory emf = OpenJPAPersistence > > > > .createEntityManagerFactory( > > > > "your/EMF/JNDI/location", (Context) null); > > > > BrokerFactory bf = OpenJPAPersistence.cast(emf); > > > > Broker b = bf.newBroker( > > > > bf.getConfiguration().getConnectionUserName(), > > > > bf.getConfiguration().getConnectionPassword(), > > > > true, // the broker is part of a JTA managed tx > > > > > > bf.getConfiguration().getConnectionRetainModeConstant(), > > > > true); // look for an existing Broker on the tx > > > > > > > > // do some JPA configuration setup. Logic stolen from > > > > // EntityManagerFactoryImpl. > > > > broker.setAutoDetach(AutoDetach.DETACH_CLOSE, true); > > > > broker.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true); > > > > broker.setDetachedNew(false); > > > > > > > > return OpenJPAPersistence.toEntityManager(b); > > > > } > > > > } > > > > > > > > Meanwhile, we really should add a couple new OpenJPAPersistence / > > > > OpenJPAEntityManagerFactory methods to help out with this type of > > > > bootstrapping. > > > > > > > > -Patrick > > > > > > > > -- > > > > Patrick Linskey > > > > BEA Systems, Inc. > > > > > > > > > > > ______________________________________________________________ > > > _________ > > > > Notice: This email message, together with any attachments, > > > may contain > > > > information of BEA Systems, Inc., its subsidiaries and > > > affiliated > > > > entities, that may be confidential, proprietary, > > > copyrighted and/or > > > > legally privileged, and is intended solely for the use of > > > the individual > > > > or entity named in this message. If you are not the > > > intended recipient, > > > > and have received this message in error, please immediately > > > return this > > > > by email and then delete it. > > > > > > > > > -----Original Message----- > > > > > From: Hans Prueller [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, February 21, 2007 1:02 AM > > > > > To: open-jpa-dev@incubator.apache.org > > > > > Subject: Howto integrate JPA within EJB2.1 session beans? > > > > > [architecture] > > > > > > > > > > Hi together, > > > > > > > > > > I'm sorry for bothering you with numerous basic questions > > > > > regarding OpenJPA and its usage but I have to migrate > > > > > existing CMP EJBs to migrate within short time to OpenJPA as > > > > > we're having stability issues with the current CMP engine. > > > > > > > > > > One last question I'd like to ask is regarding the > > > > > recommended architecture of using OpenJPA within EJB2.1 > > > > > Stateless sessino beans: > > > > > > > > > > I need to work with persistence i.e. the EntityManager > > > > > throughout all the session beans methods so my idea is to: > > > > > > > > > > - create a EntityManagerFactory in the ejbCreate() method > > > of the SLSB > > > > > - and also create the EntityManager itself in the > > > > > ejbCreeate() method and store it as a member variable > > of the SLSB > > > > > - this would allow easy access within the SB's methods by > > > > > just using the already initialized entity manager varialbe > > > > > em.createNamedQuery() .. etc. etc. > > > > > - clean up should be performed in the ejbRemove() method > > > of the SLSB > > > > > > > > > > I think doing so will allow migratino to openJPA with less > > > > > work than doing the whole lookup procedure in every method > > > > > separately. > > > > > > > > > > what do you think? are there any pitfalls i've overlooked? > > > > > > > > > > thank you for your ideas! > > > > > > > > > > regards > > > > > Hans > > > > > -- > > > > > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > > > > > Jetzt GMX ProMail testen: > > www.gmx.net/de/go/mailfooter/promail-out > > > > > > > > > > > -- > > > "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... > > > Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out > > > > > -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out
