Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Problem of eclipselink upgrade (2.0.2) - WebLogic

    Hi, I had another thought about your code pertaining to concurrency.
    Intermittent errors that are not resource related usually mean race conditions in code that may not be thread safe.
    It looks like you are using your entityManager instance on a servlet.  If the entityManager was on a session bean - atomicity of the lazy initialization of the EM would not apply.  However a servlet is multithreaded and if you are using your entityManager as an instance variable instead of a local function variable - you may get a race condition during the initial entityManager deploy/creation when another servlet request asks for the entityManager - this behavior would be undefined without synchronizing the initialization code surrounding EM creation as other servlet threads can access the entityManager instance variable before initialization completes.
    You would have a couple options...
        1 - synchronized block around the instance variable initialization (using the intrinsic reentrant lock) - good
        2 - synchronized function - but not a service method as it will queue requests making the servlet single threaded
        3 - use a java.util.concurrent.atomic.AtomicReference wrapper
        4 - initialization in the servlet constructor

    You could implement the following lock using "this" or some other threadsafe object as the lock.

        synchronized(this) {
            if(null == entityManager) {
                try {
                    entityManager = (EntityManager)ctx.lookup("java:comp/env/PersistenceName");

    This locking strategy should avoid a NPE using the EM but will queue requests until EM creation is complete - which is desirable.

    thank you
Michael O'Brien wrote:
   Hi, received your message, here to help.
   I currently see no behavioral change of a standard JTA servlet/ejb container managed EE Application
   The only difference at the EclipseLink API level is the version change from 1.2 to 2.0
   I tested our standard injection mechanism and your JNDI lookup and noted that the following element name changed from "res*" to "resource*" between 10.3.x (Sept 2008) and - check your logs for JNDI failures.

   The intermittent NPE's you describe may be related to your EM JNDI lookup, multiple/overrides or no references to our provider jar  - maybe try @PersistenceUnit EMF or @PersistenceContext EM injection if you can - for full container managed functionality.
   Are you using an unmodified server with the following shipped EclipseLink jar %server%/modules/org.eclipse.persistence_1.0.0.0_2-0.jar?
   Do you have any overrides in the commEnv.cmd script or a global shared library?
   If you are injecting or doing a lookup of your persistence unit in your WAR - do you have a persistence-context-ref? Our demo application does not require this.
   Does an application managed (bootstrap) SE RESOURCE_LOCAL persistence unit work at least via emf = Persistence.createEntityManagerFactory("PersistenceName") ... emf.createEntityManager()
   The only other issue may be that obtaining a container managed entityManager via JNDI lookup may have changed between releases - probably not since this would require a JSR-317 JEE6 spec change. 
   As a quick verification of the move from - I recently upgraded from to this time via the OEPE Oracle Enterprise Pack for Eclipse download which comes preconfigured with Eclipse 3.5 EE and WebLogic

   The test scenario involves @EJB injection on a servlet of a @Stateless session bean containing an injected @PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION) transactional JTA (Derby 10.5.3) EntityManager.  The basic demo consists of finding existing and persisting new entities. (Different from your InitialContext lookup)
       See the following page where we are posting any source, configuration details or issues needed to get a small EclipseLink JPA demo running on WebLogic 10.3.x.0

   1) Injection Test Results: OK
   The version that ships with this version of is EclipseLink 2.0.2_v20100323 rev# 6872

   I am running with the default 32 bit JRockit JVM via 32 bit Eclipse on a 64 bit Windows 7 box.
c:\opt\wls10330\JROCKI~1.0-6\bin\java -jrockit -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n -Djava.compiler=NONE  -Xms512m -Xmx512m -Dweblogic.Name=AdminServer\opt\wls10330\WLSERV~1.3\server\lib\weblogic.policy  -Xverify:none  -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.sbconsole... -Dplatform.home=C:\opt\wls10330\WLSERV~1.3 -Dwls.home=C:\opt\wls10330\WLSERV~1.3\server -Dweblogic.home=C:\opt\wls10330\WLSERV~1.3\server  -Dwlw.iterativeDev= -Dwlw.testConsole= -Dwlw.logErrorsToConsole= -Dweblogic.ext.dirs=c:\opt\wls10330\patch_wls1033\profiles\default\sysext_manifest_classpath;c:\opt\wls10330\patch_oepe1033\profiles\default\sysext_manifest_classpath;c:\opt\wls10330\patch_ocp353\profiles\default\sysext_manifest_classpath  weblogic.Server
<12-May-2010 11:58:24 o'clock AM EDT> <Info> <Management> <BEA-141107> <Version: WebLogic Server  Fri Apr 9 00:05:28 PDT 2010 1321401 >

   Running the demo Servlet client we read and persist OK"">

<12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.104--ServerSession(49448095)--EclipseLink, version: Eclipse Persistence Services - 2.0.2.v20100323-r6872>
<12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.104--ServerSession(49448095)--Server: WebLogic Server  Fri Apr 9 00:05:28 PDT 2010 1321401 >
<12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.354--ServerSession(49448095)--file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example login successful>
[EL Example]: enterprise: ApplicationService persisting: id: null state: null left: null right: null parent: HashSet@36928089 references: HashSet@36928089) on EM: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2129b5c

   2) JNDI EntityManager lookup OK

   As a secondary test I reproduced part of your config by retrofitting my app for mixed @PersistenceContext JNDI lookup instead of pure @PersistenceContext injection and was OK.

@PersistenceContext(name="ApplicationService", unitName="example", type=PersistenceContextType.TRANSACTION)
public class ApplicationService implements ApplicationServiceLocal, ApplicationServiceRemote {
   SessionContext sessionContext;
   //@PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION)      private EntityManager entityManager;

   public EntityManager getEntityManager() {
       if(null == entityManager) {
           try {
               entityManager = (EntityManager) sessionContext.lookup("ApplicationService");

new weblogic-ejb-jar.xml
       <jndi-name>ApplicationService</jndi-name>          </weblogic-enterprise-bean>

<12-May-2010 12:55:45 o'clock PM EDT> <Warning> <EJB> <BEA-010202> <Call-by-reference is not enabled for the EJB 'ApplicationService'. The server will have better performance if it is enabled. To enable call-by-reference, set the enable-call-by-reference element to True in the weblogic-ejb-jar.xml deployment descriptor or corresponding annotation for this EJB.>
[EL Example]: enterprise: Action: demo [BaseLocalObject]  for EJB: 'ApplicationService'
<12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--EclipseLink, version: Eclipse Persistence Services - 2.0.2.v20100323-r6872>
<12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--Server: WebLogic Server  Fri Apr 9 00:05:28 PDT 2010 1321401 >
<12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example login successful>
[EL Example]: enterprise: ApplicationService persisting: id: null state: null left: null right: null parent: HashSet@33933055 references: HashSet@33933055) on EM: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2984a10

   Note: as a verification that my JNDI lookup retrofitted app actually required the lookup and was not still deferring to dependency injection - I commented out the lookup

       entityManager = (EntityManager) sessionContext.lookup("ApplicationService");
   ...and got an expected NPE on any getEntityManager() call


   So JNDI lookups seem to work, however this is probably not your issue since your app runs some of the time.
   If you post the full stacktrace and configuration of your EE application we can help out further.

   thank you

Kentaro Uesugi wrote:
Hi experts.

I have been facing EclipsLink problem as following. Any sharing is appreciate.

Because of eclipsLink upgrade, I have changed to  use a server from
WebLogic including "EclipsLin 1.2.0" to WebLogic10.3.3.0
including "EclipsLink2.0.2."

With WebLogic, our system had been worked without any problem.
However, since I have changed to WebLogic10.3.3.0 including
EclipsLink2.0.2, I got a problem as following.

As I run a program, I get three kinds of cases which comes out
randomly. (I get a different result each time)

  case 1. work normal

  case 2. error: the message said "JNDI lookup error becasue of EM is null."
    I used this code following.
     --> (EntityManager)ctx.lookup("java:comp/env/PersistenceName");

  case 3.error: the message said "NullPointerException casued at
   I used this code following.
     --> ServerSession serverSession =

 I am not sure about the cause of those problems above due to the
EclipsLink upgrade or not. Any sharing is appreciate.

eclipselink-users mailing list

eclipselink-users mailing list

Back to the top