I am doing EJB lookup on application deployed on liberty inside a Listener class (sessionDestroyed method).
I am not starting any new thread. Still getting the below error
javax.naming.NamingException: CWNEN1000E: "A JNDI operation on a java:comp/env name cannot be completed because the current thread is not associated with a Java Enterprise Edition application component. This condition can occur when the JNDI client using the java:comp/env name does not occur on the thread of a server application request. Make sure that a Java EE application does not run JNDI operations on java:comp/env names within static code blocks or in threads created by that application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java:comp/env names"
Any thoughts/pointers regarding this ?
Related
In the EJB 3.1, we have annotated a method with #Asynchronous and using Future.get to fetch the results.
Question is when we do future.get(), does the database connections from the connection pool and resources are released which was being used in that async method?
Database connections are closed according to your configured connection pooling policy of the used application server.
When talking about session beans and container managed transactions, the connection is returned at the end to the transaction scope of the called business method.
Since session beans with #Asynchronous annotations do not support transaction propagation (e.g. see EJB 3.2 spec 4.5.3), a new transaction is created with every call to a business method if the method is configured with REQUIRED or REQUIRES_NEW. Thus, this transaction scope ends with the called business method returning.
There is a chance they are :) Otherwise using #Asynchronous would quickly lead to application crash due to lack of resources...
Anyway as resources are stored using Thread Local storage in Java-ee and as #Asynchronous defer the execution to a dedicated thread, the resources used there (including JCA Connection - and so database one) are also dedicated to the #Asynchronous method execution (not inherited from the caller thread).
Hello everybody I am newbie for EJB component technology and i have to learn this in order to prepare my colloquium exam. I am not sure I can understand all details of the life cycle.
The life cycle includes these steps:
-The client request to EJB Container ( but how this request could be done ? Is the location of the request I mean that remote " outside of the EJB container" or local" inside of the EJB container" is important or not?)
-By depending on the request one bean instance is created in the pool and return to the client and after use from the client it returns again in the pool ( depending on the bean type(?).
I think this scenario appropriate for the stateless session bean but I am not sure. Because in stateful session bean scenario there is no pool.)
Advance thanks for all helps.
"client" in this context just means "application code that will lookup/inject an EJB and call EJBs"; it is the opposite of "application code of the EJB itself" (which does not have a well-defined term; I've seen the term "EJB" overloaded for this meaning, or "service", etc.). Local EJB vs remote EJB is not relevant in this context, even though "client" also has a well-defined meaning for remote.
Yes, pooling of session beans refers only to stateless session beans. Stateful and singleton session beans do not have a pool. Message-driven beans can also be pooled, but they are not directly invoked by a client per se, even though there can be a logical client; e.g., the one that send the JMS message. (Entity beans can also be pooled, but they're not really relevant these days.)
I’ve tried CDI injection and #EJB injection of Stateless EJBs in a Rivr dialog. They don’t work.
I’ve also tried JNDI lookup of the EJBs through the Global JNDI name but I get following error (note I am using java:global but I get this message):
A JNDI operation on a java:comp/env name cannot be completed because the current thread is not associated with a Java Enterprise Edition application component. This condition can occur when the JNDI client using the java:comp/env name does not occur on the thread of a server application request. Make sure that a Java EE application does not run JNDI operations on java:comp/env names within static code blocks or in threads created by that application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java:comp/env names.
Is there anyway I can inject or locate CDI #Named or EJBs in a Rivr dialog?
thanks
Ignacio
I examined the Spring example in Rivr cookbook and found that the DialogFactories are executed in the ServletThread. This allowed me to perform a standard JNDI lookup using the Global JNDI name successfully and pass the EJBs to the Dialog being created.
Rivr team confirmed this by email and I am now successfully accessing EJBs that way.
I could not perform standard #Inject or #EJB injections but the JNDI "traditional" solution worked for me.
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.
We are trying to build an application, which talks to the remote EJB services and local database. EJB methods are CMT with TransactionAttributeType.REQUIRES_NEW.
My question is: how can we control EJB transactions from client?
You cannot control EJB transactions from the client. If you're using Container Managed Transactions than you've decided that the container should manage them.
The only "control" over transaction the client has is to re-invoke a method after EJBException or the implicit rollback exception.
The client invokes a method with TransactionAttributeType.REQUIRES_NEW and the rest lies in the hand of the EJB Container.