Persistence Context In EJB 3.0

I created an EJB 3.0 project in JDeveloper 10.1.3.3.0 and everything works fine in the embedded OC4J server. I am deploying the application to an OC4J instance consisting of 3 Java Virtual Machines in Oracle Application server 10.1.3 and seem to be getting a different persistence context for each virtual machine. i.e. I'll have 3 browsers that can view the same data even after updating, another 2 browsers that can't see the first 3's changes but can see changes by any browser in this group, etc.
I tried adding the below to the persistence-unit tag in the persistence.xml but it didn't seem to help.
<properties>
<property name="toplink.cache.shared.default" value="true"/>
</properties>
How do you get all connections to use the same cache?

Hi,
I am afraid, but this seems to be less a question for the JDeveloper forum but OC4J
OC4J
Frank

Similar Messages

EJB 3.0 Locking (entity not in the persistence context)

hi all,
i have some problems about locking,
i have 1 remote and one local interface
1. Remote Interface
public @Stateful
@Remote(RemoteInterface.class)
class RemoteInterfaceBean implements RemoteInterface
       @PersistenceContext(unitName = "CustomerCareOracle")
     private EntityManager oracleManager;
        public MySomeEntityObject object;
       @EJB
        MyLocalInterface inter;
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void fillMyObject(someparameters .... )
      // filling MySomeEntityObject object
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void commitMyObject()
      inter.AnotherOperatOnObject(object);
      oracleManager.persist(object);
2. My Local Interface
public @Stateless
@Local(MyLocalInterface.class)
class MyLocalInterfaceBean implements MyLocalInterface
       @PersistenceContext(unitName = "CustomerCareOracle")
     private EntityManager oracleManager;
        @TransactionAttribute(TransactionAttributeType.REQUIRED)
         public void AnotherOperatOnObject(MySomeEntityObject object)
               oracleManager.lock(object,LockModeType.READ);
// <= Here I Got An Error
               // do some operation and is succsess, It's very good ;)
}     when i tryed to lock object i got an error, i can't resolve this problem :(
can anybody help me ?
error trace
17:43:21,343 ERROR [errorCat] java.lang.IllegalArgumentException: entity not in the persistence cont
ext
        at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:336)
        at org.jboss.ejb3.entity.TransactionScopedEntityManager.lock(TransactionScopedEntityManager.
java:101)
        at com.magti.businesslayer.ejb3Fasade.oracle.ccare.TransactionFasadeBean.lockAccounts(Transa
ctionFasadeBean.java:203)
        at com.magti.businesslayer.ejb3Fasade.oracle.ccare.TransactionFasadeBean.doAfterCheck(Transa
ctionFasadeBean.java:76)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
        at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
        at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor
.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPer
sistenceContextPropagationInterceptor.java:57)     Regards,
Paata.

It looks like you're trying to call lock before the entity has been created within the persistence
context. Persist the entity within the persistence context before calling lock.

Is Persistence context thread safe? nop

In my code, i have a servlet , 2 stateless session beans:
in the servlet, i use jndi to find a stateless bean (A) and invoke a method methodA in A:
(Stateless bean A):
@EJB
StatelessBeanB beanB;
methodA(obj) {
beanB.save(obj);
(Stateless bean B, where container inject a persistence context):
@PersistenceContext private EntityManager em;
save(obj) {
em.persist(obj);
it is said entity manager is not thread safe, so it should not be an instance variable. But in the code above, the variable "em" is an instance variable of stateless bean B, Does it make sense to put it there using pc annotation? is it then thread safe when it is injected (manager) by container?
since i think B is a stateless session bean, so each request will share the instance variable of B class which is not a thread safe way.
So , could you please give me any guide on this problem? make me clear.
any is appreciated. thank you
and what if i change stateless bean B to
(Stateless bean B, where container inject a persistence context):
@PersistenceUnit private EntityManagerFactory emf;
save(obj) {
em = emf.creatEntityManager()
//begin tran
em.persist(obj);
// commit tran
//close em
the problem is i have several stateless beans like B, if each one has a emf injected, is there any problem ?

Hi Jacky,
An EntityManager object is not thread-safe. However, that's not a problem when accessing an EntityManager from EJB bean instance state. The EJB container guarantees that no more than one thread has access to a particular bean instance at any given time. In the case of stateless session beans, the container uses as many distinct bean instances as there are concurrent requests.
Storing an EntityManager object in servlet instance state would be a problem, since in the servlet programming model any number of concurrent threads share the same servlet instance.
--ken

Transactions, Persistence Contexts and Entity Managers... Oh My!

Hi
I am just getting into J2EE and EJB3. I have no prior experience with EJB2, we avoided it with our own POJO data access framework. With the advent of EJB3 we would like to use it in a new application.
I am reading the book "Pro EJB 3" by Ketih and Schincariol and am having trouble wrapping my head around then Entity Manager chapter. I don't think it's any fault of the authors, but somehow it's just not coming together in my head. Perhaps it's because I have no real prior EJB experience.
Can anyone point me to a resource that gives an overview of the relationships between Transactions, Persistence Contexts and Entity Managers? Or perhaps I just have to keep mulling it over until it all comes together...?
Thanks in advance!

Hi Shelli,
I haven't read that book but I don't know of a good writeup of the tx topic specifically outside
of the spec itself. There are certainly a lot of combinations, between container-managed
vs. bean-managed EntityManagers, and JTA vs. resource-local. However, the
common usage case within Java EE -- container-managed and JTA -- is very simple.
In this case, the container automatically associates the persistence context with the
active global transaction. If you make a call to another Java EE component within the
same transaction and that component accesses a container-managed EntityManager
for the same persistence unit, the persistence context is automatically propagated so
that both components "see" the same persistence context.
--ken

Why not use EXTENDED persistence context?

When would you not ever use EXTENDED persistence context in a stateful session bean (which is the only EJB type it can be used in)?
To me it seems that the code is cleaner (no unnecessary merge() or whatever) and it only makes sense as a stateful session bean is used to represent conversational state over multiple client calls...by setting an EXTENDED persistence context you recognize that there is a conversation happening.
I'm not seeing when you'd not want to use EXTENDED persistence context (I understand it's not the default persistence context).
Your thoughts please...
Thanks.

For the use-case you mentioned an extended persistence context is a natural fit.
It really depends on whether the semantics of your SFSB operations call for
the references to the same entity objects to be maintained across transactions.
E.g., you might have an SFSB whose state is not derived from persistence state
but which just occasionally makes a database query as part of some of its
business operations. In that case there wouldn't be any reason to use an
extended persistence context.
--ken

What is persistence contexts collision?

I'm trying to learn more on persistence in EJB, specially about persistence context. I know than a persistence context is created when a method than requires a transaction have been called and no persistence context existed before. I also know than a persistence context is destroyed when there is no method in action than requires a transaction, except if the EntityManager scope is extended. In this case, the persistence context will be destroyed when the session bean than contains the EntityManager is going to be destroyed. I read "Pro EJB 3 Java Persistence API" by Mike Keith and Merrick Schincariol. In this e-book, it mention than two persistence contexts can collide. Collisions between persistence contexts happen when we use different kinds of EntityManager. This very special part of the book brought to me a lot of questions. I want to know more about persistence context, so these are my questions :
- First of all, how many persistence contexts from the same persistence unit (EntityManagerFactory) can exist at the same time? If more than one is possible, in which context it is possible and how the propagation works when it happen?
- Second, when I'm using a new EntityManager while a persistence context created by the same persistence unit exist, is this new EntityManager will be related to the persistence context than already exists?
- Finally, what is a collision of persistence contexts? When two persistence contexts collide? What are the consequences?
- For example, if I use a stateful session bean with an extended scope EntityManager, then I call a method of this stateful session bean than call a method of a stateless session bean, and the last method use a transaction scope EntityManager, can I get a collision of two persistence contexts? I mean, will the persistence context in the stateful session bean collide with the persistence context in the stateless session bean?
Thank you in advance from your answer.
Dominic
P.S. You can answer to me in french if it's easier for you.

morphian wrote:
Hi,
I'm a total noob. I've been reading and following examples from books but I haven't read anything about how persistence really works? How does it help my session beans to access or make transactions to the database?
How does it actually work? What if I just make direct queries from my session beans without the help of the EntityManager or the Peristence API? What's the difference?
You have to code the stuff that EntityManager and Persistence are doing for you.
Like this for example:
Customer requestCustomer = em.find(Customer.class.customerId);Does it mean that the Persistence API keeps the object alive in the Customer Entity? For how long? Until the application is closed? Complicated. Not enough info.
If so, what happens if the user opens the application again and looks for that object?
Open the app and the object will be refreshed from that data store. Hence the word "persistent".
Why can't I just make a direct query to see if that customerId exists in the database?
You can.
I hope you guys don't mind my questions... I just really want to learn this stuff and I gotta let things out of my head. Hope you can help. Thanks!This isn't the way to do it, but it's a start.
%

Extended Persistence Context And user transaction

Hello
I use Extended persistence context with stateful session bean in my app, but when i persist object it does not store in database,i dont know whats wrong:
@Stateful
@TransactionManagement(TransactionManagementType.BEAN)
public class ProfessionAction implements ProfessionLocal {
     @PersistenceContext(type = PersistenceContextType.EXTENDED)
     private EntityManager em;
     @Transient
     private Logger log;
     @Resource
     private UserTransaction ut;
     public Profession add( Profession p) {
          try {
               log.info("Adding Profession...");
               ut.begin();
               em.persist(p);
               ut.commit();
               log.info("Profession Added...");
          } catch (Exception ex) {
               log.error(ex.getMessage(), ex);
          return p;
     }

What if you change the code to this:
@Stateful
@TransactionManagement(TransactionManagementType.BEAN)
public class ProfessionAction implements ProfessionLocal {
@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EntityManager em;
@Transient
private Logger log;
public Profession add( Profession p) {
try {
log.info("Adding Profession...");
em.getTransaction().begin();
em.persist(p);
em.getTransaction().commit();
log.info("Profession Added...");
} catch (Exception ex) {
log.error(ex.getMessage(), ex);
return p;
}?

Persistence shared across EJB and WAR projects

Hi,
I have created an Enteprise Application in netbeans which has an EJB project and a web archive. This may be expanded further at a later time by having an application client as well. I am still fairly new to this so you'll have to forgive me if this is a simple problem. I have a persistence unit (persistence.xml) that I need to share across both WAR and EJB, but so far am not having much luck. I have read various responses and they say I should have the EAR constructed as the following:
project.ear
=======
META-INF/MANIFEST.MF
lib/persistence.jar
---> META-INF
---> META-INF/persistence.xml
project-ejb.jar
project-war.war
When I try and compile it though I get the following messages from both EE modules:
Note: The persistence xml file [META-INF/persistence.xml] was not found. NO GENERATION will occur!! Please ensure a persistence xml file is available either from the CLASS_OUTPUT directory [META-INF/persistence.xml] or using the eclipselink.persistencexml property to specify its location.
I have tried copying the persistence.xml into the main META-INF directory in the EAR file and setting the eclipselink.persistencexml=META-INF/persistence.xml, but it still shows the same thing. Is this a classpath issue or is there something else wrong?
Many thanks

The EAR is a good idea, but you put the META-INF/persistence.xml in your ejb module. The EJB is where you want to do all your (container managed) transactional stuff, so make calls into your EJBs from the WAR in stead of trying to share a persistence unit across modules.

Bean-managed persistence (BMP) in EJB 3.0

I've been on the google for a few days now and haven't found one single notion on bean-managed persistence in EJB 3.0 specification. Even the official specification PDFs don't mention it :(
Help! I need BMP! Does anybody know what's the situtation in EJB 3.0? Can I and how mark an entity bean to be bean-managed persistent and use ejbLoad and ejbStore functions like in the EJB 2.0 or something like that?
Tnx in advance,
Igor

Tnx Frank, I was afraid of that :(
I think that is a step back for the EJB technology. Now it is fixed to the table structure, every change in the database calls for a re-desing, re-compilation and re-deplyoment.
With BMP in EJB 2.1 one was able to build a bean that modifies itself according to the table structure dinamically. Is there any way to do it in EJB 3.0?
Igor

Deploying persistence.xml in ejb-jar componts

Hi,
If you are deploying ejb-jar components which are packaged independently and are remote components but they all access the same database, do you put the persistence.xml in the META-INF of each component (ejb-jar). If not, where would it go?
I can find lots of references to having a single persistence.xml with many configurations but if (theoretically) each bean is deployed on a separate JVM/Container how would it access the persistence.xml?
Thanks.

If you are deploying the EJB JARs to different Java EE servers, then yes, each EJB JAR needs its own persistence.xml. You would configure each Java EE server to point to the same JDBC resource.
If you are deploying them all to the same server, you should package the entity classes into a single JAR file, and include that JAR file in an EAR with the other EJB JARs. In that scenario, persistence.xml is in the JAR's META-INF directory. The JAR file can either be in the top-level of the EAR, or in the EAR's library directory. In this case, the scope of the persistence unit is the entire EAR.
-ian

Implicitly Passing a Custom Context with EJB Invocations

Dimitri, this is most likely one for you.
We have a need to implicitly pass contextual information with EJB
invocations. I'd also like to be able to intercept/filter invocations.
The current approach autogenerates subclasses for the bean
implementations. In these subclasses, the methods take an additional
context parameter. From the client perspective, the business delegates
implicitly provide this parameter.
I'd like to solve this without code generation.
The current approach I'm considering is to have a generic command EJB.
This stateless session bean will take a method signature, method
parameters, and a context object. The command EJB will delegate these
invocations to the actual EJBs.
I will get the client to go through this command EJB by intercepting the
home lookups. I will wrap the initial context. Using dynamic proxies,
the new initial context will return a wrapped stub that will actually go
through the command bean, implicitly passing the thread local context.
So far as the command bean's configuration goes, I will set to the pool
size very high (the sum of all of the other stateless session bean pool
sizes perhaps). I will set the transaction type to Supports and pass on
any exceptions.
Can anyone think of a better way to go about this?
Thanks,
Bob

Why do you need the custom context? I have worked with an application that held the SessionContext and wrapped all the methods of the EJB context. This was a maintenance problem because changes to the EJB spec caused the methods to change and therefore the calling code.
Are you trying to insulate your POJO code from EJB specific classes?

Can i pass the persistence unit to the Ejb before it inject the entity mana

Hey,
The user in my system can create his personal schema, so i need to work with multiple schemas.
As i understand i need to create at run time persistence unit for each schema.
The problem is that my DAO i inject the entity manager in the following way:
@PersistenceContext(persistenceUnit="bla-bla")
public void setEntityManager(EntityManager em) {
this.em = em;
}i need to write the persistence unit name hard coded.
How can i solve this?
Thank you

There's no way to get this kind of dynamic association to a persistence unit for container-managed
persistence contexts. You'll need to explicitly create an EntityManager using the
EntityManagerFactory API, where you specify the name of the persistence unit at runtime. Even in
that case, the persistence unit must already be defined.
--ken

SAS9.1 Persistence and EJB lookups (not registered in JNDI?)

I am trying to deploy a very basic EJB3 module to test my learning. The module deploys via the Admin Console without apparnet error. Unfortunately, when using the generated test page for the web-service, I am having total failure which seems to be around the persistence unit and EJBs not being created in the JNDI.
I have an @Stateless/@WebService bean:
package com.flexit.buslogic;
import java.util.logging.Level;
import javax.ejb.Stateless;
import javax.ejb.EJB;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import com.flexit.persistence.eao.OwnerFacade;
@WebService
@Stateless
public class CreateOwner {
     @EJB
     private OwnerFacade ownerFacade;
     public CreateOwner(){}
     @WebMethod
     public Integer addOwner (
               @WebParam(name="Name") String name){
         LogUtil.log("Add owner request " +
                    "received for "+name,
                    Level.INFO, null);
        return ownerFacade.findAll().size();
}The OwnerFacade EJB injection fails with avax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJBIf I instantiate a 'normal' reference to OwnerFacade (ie OwnerFacade ownerFacade = new OwnerFacade(); I get a similar error in the OwnerFacade EJB in relation to an attempt to inject an EntityManager:
package com.flexit.persistence.eao;
import java.util.List;
import java.util.logging.Level;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import com.flexit.persistence.LogUtil;
import com.flexit.persistence.Owner;
@Stateless
public class OwnerFacade implements OwnerFacadeLocal, OwnerFacadeRemote {
     // fields
     @PersistenceContext(unitName="FlexIBuildPU")
     private EntityManager entityManager;
     public OwnerFacade () {
          if (entityManager == null) {
               LogUtil.log("unable to get an Entity Manager Instance", Level.SEVERE, null);
...The constructor logs that the entityManager is, indeed, null.
I have tried the code on SAS9 and 9.1 and using the default JavaDB and a MySQL connection pool (successful ping) and datasource (named 'jdbc/FlexDBDS') created through the Admin Console. The persistence unit is defined in a persistence.xml file in the META-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
     <persistence xmlns="http://java.sun.com/xml/ns/persistence"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
         http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
          <persistence-unit name="FlexIBuildPU" transaction-type="JTA">
               <jta-data-source>jdbc/FlexDBDS</jta-data-source>
          </persistence-unit>
</persistence>Can anyone please save me from tearing my hair out (more)?

Have managed to resolve. There were two problems
First I was attempting to access a session bean directly rather than via an interface (eejit!) - ie:
@EJB OwnerFacade ownerFacadewhen it should have been:
@EJB OwnerFacadeLocal ownerFacadeSecond, the persistence unit wasn't created properly. In playing around with persistence.xml I moved from:
<?xml version="1.0" encoding="UTF-8"?>
     <persistence xmlns="http://java.sun.com/xml/ns/persistence"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
         http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
          <persistence-unit name="FlexIBuildPU" transaction-type="JTA">
               <description>This unit manages BMS units, owners, offers, and acceptance.</description>
               <jta-data-source>jdbc/FlexDBDS</jta-data-source>
               <properties>
                      <property name="toplink.jdbc.driver" value="com.mysql.jdbc.Driver"/>
                      <property name="toplink.ddl-generation" value="create-tables"/>
               </properties>
          </persistence-unit>
</persistence>to:
<?xml version="1.0" encoding="UTF-8"?>
     <persistence xmlns="http://java.sun.com/xml/ns/persistence"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
         http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
          <persistence-unit name="FlexIBuildPU" transaction-type="JTA">
               <description>This unit manages BMS units, owners, offers, and acceptance.</description>
               <jta-data-source>jdbc/FlexDBDS</jta-data-source>
               <properties>
                      <property name="toplink.jdbc.driver" value="com.mysql.jdbc.Driver"/>
                      <property name="toplink.application-location" value="C:\ddl\flexdb\"/>
                      <property name="toplink.create-ddl-jdbc-file-name" value="create.sql"/>
                      <property name="toplink.drop-ddl-jdbc-file-name" value="drop.sql"/>
                      <property name="toplink.ddl-generation.output-mode" value="both"/>
                      <property name="toplink.ddl-generation" value="create-tables"/>
               </properties>
          </persistence-unit>
</persistence>It seems the very action of writing the sql to file helps with the binding. It seems so extraordinary that I think I must of made another mistake which was corrected along the way. In any event, the properties specifying output files may prove useful to others. :)

Update form another EJB with DAO persistence

We have two modules with EJB Session, stateless, with CMT requeried in all methods, the first module has the persistence tier wiht DAOs pattern and the other module uses TopLink. We are using JSF as framework in the presentation layer, when we are going to update the database from web form a backing bean JSFcalls the first EJB (DAOs persistence) and this EJB invokes the other EJB (Toplink persistence). and throws the next exception
05/10/31 17:12:12 java.lang.NullPointerException
05/10/31 17:12:12      at oracle.toplink.internal.indirection.UnitOfWorkValueHolder.getValueFromServerObject(UnitOfWorkValueHolder.java:105)
05/10/31 17:12:12      at oracle.toplink.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:144)
05/10/31 17:12:12      at oracle.toplink.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:64)
05/10/31 17:12:12      at oracle.toplink.internal.indirection.BasicIndirectionPolicy.cloneAttribute(BasicIndirectionPolicy.java:88)
05/10/31 17:12:12      at oracle.toplink.mappings.ForeignReferenceMapping.buildClone(ForeignReferenceMapping.java)
05/10/31 17:12:12      at oracle.toplink.internal.descriptors.ObjectBuilder.populateAttributesForClone(ObjectBuilder.java:1492)
05/10/31 17:12:12      at oracle.toplink.publicinterface.UnitOfWork.cloneAndRegisterNewObject(UnitOfWork.java:601)
05/10/31 17:12:12      at oracle.toplink.publicinterface.UnitOfWork.internalRegisterObject(UnitOfWork.java:2294)
05/10/31 17:12:12      at oracle.toplink.internal.sessions.MergeManager.registerObjectForMergeCloneIntoWorkingCopy(MergeManager.java:688)
05/10/31 17:12:12      at oracle.toplink.internal.sessions.MergeManager.mergeChangesOfCloneIntoWorkingCopy(MergeManager.java:397)
05/10/31 17:12:12      at oracle.toplink.internal.sessions.MergeManager.mergeChanges(MergeManager.java:181)
05/10/31 17:12:12      at oracle.toplink.publicinterface.UnitOfWork.mergeClone(UnitOfWork.java:2634)
05/10/31 17:12:12      at oracle.toplink.publicinterface.UnitOfWork.deepMergeClone(UnitOfWork.java:1231)
05/10/31 17:12:12      at siscoi.declaracionescambio.business.DeclaracionesCambioMngr.grabarDeclaracionCambio(DeclaracionesCambioMngr.java:222)
when the objects are new the TopLink framework works good, but when the object already exist in the DB, does not make the update an thorw the null pointer exception why?.
We implements a Client Class to only test the EJB with Toplink persistence. In this class read a object from de database and i modify the object and calls the update method and the update works good.
Container oc4j 10.1.2
Toplink 9.0.4
jdk 1.4.2.04
please help me!!

It looks like the issue is occurring because the object that you are merging is a new object, or TopLink thinks it is a new object and it is being registered as a new object. The new object has a non-instantiated value-holder that seems to have been serialized so can no longer be instantiated, but the relationship is required to persist the new object.
My guess is that the object is not new, but existing, and the issue is most likely with your does-exist-check option. The original object may no longer be in the cache, so you most likely need to use check-database for your descriptor's does-exist option, instead of the default of check-cache.

EJB initial Context

Any one have set their initial context for EJB for J2eesdk kit similar to Weblogic initial context please mail me i will be grateful to you
mail:[email protected]

Have a look at the ServiceLocator pattern, this caches references found and has a method getInitialContext() which instantiates an InitialContext and sets it as a member value of the ServiceLocator which itself is a Singelton.

Persistence Context In EJB 3.0

Similar Messages

Maybe you are looking for