So yes, I believe that unless a container "knows" that a bound value is actually sharable (see below), it will generally serialize the instance and then deserialize it for each caller. The way to make this operation perform well (short of telling the container to share it) is to implement the Referenceable contracts.
I can drag out more details if there is interest. Or you can look at 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 factory and then deserializing it or something.From J2EE 1.4 spec, page 59 (J2EE.5.2 Java Naming and Directory Interface:In general, lookups of objects in the JNDI java: namespace are required to return a new instance of the requested object every time. Exceptions areallowed for the following:- The container knows the object is immutable (for example, objects of type java.lang.String), or knows that the application can't change the state ofthe object.-The object is defined to be a singleton, such that only one instance of the object may exist in the JVM. -The name used for the lookup is defined to return an instance of the object that might be shared. The name java:comp/ORB is such a name.In these cases, a shared instance of the object may be returned. In all other cases, a new instance of the requested object must be returned on eachlookup. Pinaki Poddar BEA Systems 415.402.7317 -----Original Message----- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 11:11 PM To: open-jpa-dev@incubator.apache.orgSubject: RE: EMF JNDI lookup is starting openJPA every time - was: Howto integrate JPA within EJB2.1 session beans?It should be going through the following code:public static OpenJPAEntityManagerFactory createEntityManagerFactory(String jndiLocation, Context context) { if (jndiLocation == null) throw new NullPointerException("jndiLocation == null"); try { if (context == null) context = new InitialContext(); Object o = context.lookup(jndiLocation);return (OpenJPAEntityManagerFactory) 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 happen. But maybe something funky is happening with JNDI serializing the factory and then deserializing it or something.Do you have any means of getting a stack from where the creation is happening? It'd be great to get a bit more context about what's going on.-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:[EMAIL PROTECTED] 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 = 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 - OpenJPA will now connect to the database to attempt to determine what typeof 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. I ambinding the EMF somewhen at bootstrapping time with final EntityManagerFactory emFactory = Persistence .createEntityManagerFactory("lbsims"); Context ictx = 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 = OpenJPAPersistence .createEntityManagerFactory(EMF_JNDI_LOCATION, (Context) null); Any Idea what could be wrong here? regards, HANS-----Ursprüngliche Nachricht----- Von: Patrick Linskey [mailto:[EMAIL PROTECTED] 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 beOpenJPAPersistence.toBrokerFactory(emf). Sorryabout that. -Patrick -- Patrick Linskey BEA Systems, Inc.______________________________________________________________ _________Notice: This email message, together with any attachments,may containinformation of BEA Systems, Inc., its subsidiaries andaffiliatedentities, that may be confidential, proprietary,copyrighted and/orlegally privileged, and is intended solely for the use ofthe individualor entity named in this message. If you are not theintended recipient,and have received this message in error, please immediatelyreturn thisby email and then delete it.-----Original Message----- From: Hans J. Prueller [mailto:[EMAIL PROTECTED] 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 = 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üngliche Nachricht----- Von: Patrick Linskey [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Februar 2007 23:22 An: open-jpa-dev@incubator.apache.org Betreff: RE: RE: Howto integrate JPA within EJB2.1session 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-161tracks theissue; I've got a patch that I'll submit once some moreeyes look at it.-Patrick -- Patrick Linskey BEA Systems, Inc.______________________________________________________________ _________Notice: This email message, together with any attachments,may containinformation of BEA Systems, Inc., its subsidiaries andaffiliatedentities, that may be confidential, proprietary,copyrighted and/orlegally privileged, and is intended solely for the use ofthe individualor entity named in this message. If you are not theintended recipient,and have received this message in error, please immediatelyreturn thisby 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 EMFor 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 newbroker/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 methodsall create newEMs. The broker code will look up one associated withthe currenttransaction, which is what you're looking for. Unfortunately, that means that we're using a synchronizedblock duringthe lookup. If it looks like EM lookup is a scalabilityissue for yourapp, 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 complexto integrateJPA into an existing Java2EE 1.4 AppServerenvironment.. *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 EMFor 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 abrokerfactory now? I//would guess the "broker" is something like amore abstract//concept of entitymanager(factory)? //why do I have to create a newbroker/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 txbf.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 tointegrateJPA into an existing Java2EE 1.4 AppServerenvironment.. *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.1session beans?[architecture]Another common technique is to get an EMF intoJNDI, eitherby using astartup hook or deploying OpenJPA as a JCA RAR. Are you looking to integrate OpenJPA with yourcurrent managedtransaction? If so, I'd be careful about creating an EM inejbCreate(),as its lifecycle is related to the life of the SLSB,not to thetransactional context (the SLSB might be pooled). So, I'djust try toget the EMF into JNDI when the server starts(creating EMFsis slow).Then, you could avoid having to use your own ThreadLocalwork by usingthe 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 JTAmanaged txbf.getConfiguration().getConnectionRetainModeConstant(),true); // look for an existing Brokeron the tx// do some JPA configuration setup. Logicstolen 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 newOpenJPAPersistence /OpenJPAEntityManagerFactory methods to help out withthis type ofbootstrapping. -Patrick -- Patrick Linskey BEA Systems, Inc._______________________________________________________________________Notice: This email message, together with anyattachments,may containinformation of BEA Systems, Inc., itssubsidiaries andaffiliatedentities, that may be confidential, proprietary,copyrighted and/orlegally privileged, and is intended solely for the use ofthe individualor entity named in this message. If you are not theintended recipient,and have received this message in error, pleaseimmediatelyreturn thisby 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.1session beans?[architecture] Hi together, I'm sorry for bothering you with numerous basicquestionsregarding OpenJPA and its usage but I have to migrate existing CMP EJBs to migrate within short timeto OpenJPA aswe're having stability issues with the currentCMP 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 myidea is to:- create a EntityManagerFactory in theejbCreate() methodof the SLSB- and also create the EntityManager itself in the ejbCreeate() method and store it as a member variableof the SLSB- this would allow easy access within the SB'smethods byjust using the already initialized entitymanager varialbeem.createNamedQuery() .. etc. etc. - clean up should be performed in the ejbRemove() methodof the SLSBI think doing so will allow migratino toopenJPA with lesswork than doing the whole lookup procedure inevery methodseparately. what do you think? are there any pitfalls i'veoverlooked?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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature