From open-jpa-dev-return-2475-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Tue Feb 27 23:32:47 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 9000 invoked from network); 27 Feb 2007 23:32:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Feb 2007 23:32:46 -0000 Received: (qmail 55049 invoked by uid 500); 27 Feb 2007 23:32:55 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 55032 invoked by uid 500); 27 Feb 2007 23:32:55 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 55022 invoked by uid 99); 27 Feb 2007 23:32:55 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Feb 2007 15:32:55 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [192.18.42.249] (HELO nwk-ea-fw-1.sun.com) (192.18.42.249) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Feb 2007 15:32:42 -0800 Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1RNWGsO028332 for ; Tue, 27 Feb 2007 15:32:16 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE500J01AM3UX00@d1-sfbay-10.sun.com> (original mail from Craig.Russell@Sun.COM) for open-jpa-dev@incubator.apache.org; Tue, 27 Feb 2007 15:32:15 -0800 (PST) Received: from [129.145.133.119] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE500CSPAPRDP30@d1-sfbay-10.sun.com> for open-jpa-dev@incubator.apache.org; Tue, 27 Feb 2007 15:32:15 -0800 (PST) Date: Tue, 27 Feb 2007 15:32:17 -0800 From: Craig L Russell Subject: Re: EMF JNDI lookup is starting openJPA every time - was: Howto integrate JPA within EJB2.1 session beans? In-reply-to: <5C219175D559A64D8C2CC65E41D36856CDBA55@repbex01.amer.bea.com> Sender: Craig.Russell@Sun.COM To: open-jpa-dev@incubator.apache.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-91-1038410259; micalg=sha1 References: <7D856CDFE035FF45A0420ACBD71BDD63034FE0F7@repbex02.amer.bea.com> <001001c758a7$41a31ce0$0500a8c0@burns> <7D856CDFE035FF45A0420ACBD71BDD63035929BF@repbex02.amer.bea.com> <5C219175D559A64D8C2CC65E41D36856CDBA55@repbex01.amer.bea.com> X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-91-1038410259 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed We had a similar issue with the JDO Reference Implementation. What we =20= ended up with was implementing the naming.Referenceable interface and =20= writing our own externalization protocols that basically allowed the =20 container to create new instances of our Factory that were actually =20 trivial wrappers that delegated to the real Factory. So yes, I believe that unless a container "knows" that a bound value =20 is actually sharable (see below), it will generally serialize the =20 instance and then deserialize it for each caller. The way to make =20 this operation perform well (short of telling the container to share =20 it) is to implement the Referenceable contracts. I can drag out more details if there is interest. Or you can look at =20 the implementation of FOStorePMF in the Apache JDO project. Craig On Feb 27, 2007, at 9:47 AM, Pinaki Poddar wrote: >> But maybe something funky is happening with JNDI serializing the =20 >> factory and then deserializing it or something. > > =46rom J2EE 1.4 spec, page 59 (J2EE.5.2 Java Naming and Directory =20 > Interface: > > In general, lookups of objects in the JNDI java: namespace are =20 > required to return a new instance of the requested object every =20 > time. Exceptions are > allowed for the following: > - The container knows the object is immutable (for example, objects =20= > of type java.lang.String), or knows that the application can't =20 > change the state of > the object. > -The object is defined to be a singleton, such that only one =20 > instance of the object may exist in the JVM. > -The name used for the lookup is defined to return an instance of =20 > the object that might be shared. The name java:comp/ORB is such a =20 > name. > > In these cases, a shared instance of the object may be returned. In =20= > all other cases, a new instance of the requested object must be =20 > returned on each > lookup. > > > Pinaki Poddar > BEA Systems > 415.402.7317 > > > -----Original Message----- > From: Patrick Linskey [mailto:plinskey@bea.com] > Sent: Monday, February 26, 2007 11:11 PM > To: open-jpa-dev@incubator.apache.org > Subject: RE: EMF JNDI lookup is starting openJPA every time - was: =20 > Howto integrate JPA within EJB2.1 session beans? > > It should be going through the following code: > > public static OpenJPAEntityManagerFactory =20 > createEntityManagerFactory > (String jndiLocation, Context context) { > if (jndiLocation =3D=3D null) > throw new NullPointerException("jndiLocation =3D=3D = null"); > > try { > if (context =3D=3D null) > context =3D new InitialContext(); > > Object o =3D context.lookup(jndiLocation); > return (OpenJPAEntityManagerFactory) =20 > PortableRemoteObject.narrow(o, > OpenJPAEntityManagerFactory.class); > } catch (NamingException ne) { > throw new ArgumentException(_loc.get("naming-exception", > jndiLocation), new Throwable[]{ ne }, null, true); > } > } > > I don't see anything in there that would be causing a creation to =20 > happen. But maybe something funky is happening with JNDI =20 > serializing the factory and then deserializing it or something. > > Do you have any means of getting a stack from where the creation is =20= > happening? It'd be great to get a bit more context about what's =20 > going on. > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > > ______________________________________________________________________=20= > _ > Notice: This email message, together with any attachments, may =20 > contain information of BEA Systems, Inc., its subsidiaries =20 > and affiliated entities, that may be confidential, proprietary, =20= > copyrighted and/or legally privileged, and is intended solely for =20 > the use of the individual or entity named in this message. If you =20 > are not the intended recipient, and have received this message in =20 > error, please immediately return this by email and then delete it. > >> -----Original Message----- >> From: Hans J. Prueller [mailto:hans.prueller@gmx.net] >> Sent: Saturday, February 24, 2007 10:36 PM >> To: open-jpa-dev@incubator.apache.org >> Subject: EMF JNDI lookup is starting openJPA every time - >> was: Howto integrate JPA within EJB2.1 session beans? >> >> Hi together, Patrick, >> >> the code you suggested for doing a helper method that deals with the >> EMF JNDI lookup and the EM creating within our J2EE1.4 app basically >> works fine, but as you perhaps may remember I asked why the method is >> called "create": >> >> EntityManagerFactory myemf =3D >> OpenJPAPersistence.createEntityManagerFactory(strJNDILocation, >> (Context)null); >> >> It seems that the method above really creates a NEW EMF on every >> invocation! >> I checked the logs of my application and I see the following messages >> on every invocation of my PersistenceService.getEntityManger() >> method (which >> does the above lookup and some more ..) >> >> 2007-02-25 07:27:05,687 : PersistenceService.getEntityManager >> : creating a >> fresh >> , clean EntityManager from JNDI EMF. >> 15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5] >> openjpa.Runtime - >> Starti >> ng OpenJPA 0.9.7-incubating-SNAPSHOT >> 15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5] >> openjpa.jdbc.JDBC - >> Open >> JPA will now connect to the database to attempt to determine what =20 >> type >> of databa se dictionary to use. To prevent this connection in the >> future, set your openjp a.jdbc.DBDictionary configuration property to >> the appropriate value for your dat abase (see the documentation for >> available values). >> 15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5] >> openjpa.jdbc.JDBC - >> Usin >> g dictionary class >> "org.apache.openjpa.jdbc.sql.MySQLDictionary" (MySQL 5.0.27-c >> ommunity-nt ,MySQL-AB JDBC Driver mysql-connector-java-5.0.4 ( $Date: >> 2006-10-19 >> 17:47:48 +0200 (Thu, 19 Oct 2006) $, $Revision: 5908 $ )). >> 15 lbsims INFO [RMI TCP Connection(35)-192.168.0.5] >> openjpa.MetaData - >> Found >> 1 classes with metadata in 0 milliseconds. >> >> >> It seems that OpenJPA is now bootstrapping everytime I access it. =20 >> I am >> binding the EMF somewhen at bootstrapping time with >> >> final EntityManagerFactory emFactory =3D Persistence >> .createEntityManagerFactory("lbsims"); >> >> Context ictx =3D new InitialContext(); >> ictx.bind(PersistenceService.EMF_JNDI_LOCATION, emFactory); >> >> The lookup uses the same constants, so the EMF in JNDI should be >> found? >> >> EntityManagerFactory emf =3D OpenJPAPersistence >> =09 >> .createEntityManagerFactory(EMF_JNDI_LOCATION, (Context) null); >> >> Any Idea what could be wrong here? >> >> regards, >> HANS >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Patrick Linskey [mailto:plinskey@bea.com] >>> Gesendet: Freitag, 23. Februar 2007 18:46 >>> An: open-jpa-dev@incubator.apache.org >>> Betreff: RE: TYPO? Howto integrate JPA within EJB2.1 session beans? >>> [architecture] >>> >>> Typo indeed. It should be >> OpenJPAPersistence.toBrokerFactory(emf). Sorry >>> about that. >>> >>> -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 J. Prueller [mailto:hans.prueller@gmx.net] >>>> Sent: Friday, February 23, 2007 9:43 AM >>>> To: open-jpa-dev@incubator.apache.org >>>> Subject: RE: TYPO? Howto integrate JPA within EJB2.1 session >>>> beans? [architecture] >>>> >>>> Patrick, >>>> >>>> I'm currently trying your tip with a PersistenceService util class >>>> doing the lookup of a synchronized entity manager. The problem is >>>> that your sample code does not work! >>>> >>>> in fact the statement >>>> >>>> final BrokerFactory bf =3D OpenJPAPersistence.cast(emf); >>>> >>>> is the problem. the above "cast" does not return a BrokerFactory >>>> instance! >>>> >>>> I am using a 2 days old nightly snapshot 0.9.7 build >>>> >>>> Where is the problem? >>>> >>>> Hans >>>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: Patrick Linskey [mailto:plinskey@bea.com] >>>>> Gesendet: Donnerstag, 22. Februar 2007 23:22 >>>>> An: open-jpa-dev@incubator.apache.org >>>>> 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:plinskey@bea.com] >>>>>> 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 =3D 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:hans.prueller@gmx.net] >>>>>>> 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 =3D 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 =3D OpenJPAPersistence.cast(emf); >>>>>>> Broker b =3D 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" >>>>>>> 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 =3D OpenJPAPersistence >>>>>>>> .createEntityManagerFactory( >>>>>>>> "your/EMF/JNDI/location", (Context) null); >>>>>>>> BrokerFactory bf =3D OpenJPAPersistence.cast(emf); >>>>>>>> Broker b =3D 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:hans.prueller@gmx.net] >>>>>>>>> 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 >>>>>>> >>>>>> >>>> >>>> >> >> Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp! --Apple-Mail-91-1038410259 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI3MjMzMjE4WjAjBgkqhkiG9w0B CQQxFgQU5e6TkCnq9d2iiyF69YpQT1NSiSUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAK98gdw1ILThFJBoxAr6ABaOThJEBvNr Hkk0bQT3B0QabR80m7BQIZkt+FqongYHycjsUZxIECHT+VqXJ0vvcD7bQ7HdN/BH5thmpDmqHN1+ i7dzXFCcuomQyWGJAkshwUnilNGtu9MAfS6mrp9hTeEQbZQGDVF4hTjQ5fVvT4Im7iSw9V3sOYGz VWId/5waBbV7yNEkQDqIyQgvw7LAOteKc3TbRt4kJQc0LyYQAAt/PQXfNHVVc+hhD3bJD6tiLsYw qDp2Q6AiM2vCfpFLJMfatXML3xeU6Tb4q64jt3ijah696XlJKh2J5jxyExSwBakhaDxhF9V2ZrZ+ motyXwIAAAAAAAA= --Apple-Mail-91-1038410259--