How to control transaction of CMT EJB from client - ejb

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.

Related

Does #Asynchronous in EJB 3.1 closes/releses the connection when the Async method is completed

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).

EJB lifecycle ( request from client)

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.)

Difference between EJB and Servlet?

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.

Should I bind JDBC connection to servlet thread?

I'm using jndi to access to dbcp datasource.
In scope of one servlet request each time call static_dataSource.getConnection() returns new connection.
In hibernate there is a function getCurrentSession(). As far as I understand this function return connection that binded to current thread. Should I bind my jdbc connection to thread also?
My goal is call complex business logic in scope of one transaction that contains many DAO calls, per one http request. Like in Spring I can annotate whole service class with #Transactional.
I'd recommend that you not bind a JDBC connection to a thread. Use a connection pool and hang onto the connection for the shortest time possible: acquire from pool, perform operation, close the connection, return to pool.
Your persistence code ought to be completely separate from the web tier. You should be able to test and use it independent of the web tier. Anything that you do to tie the two together will diminish the effectiveness of the persistence tier.

Flex remote object performance

Our flex client needs to invoke server side EJB3 session bean. For each module we have seperate session bean.
Whether it is best to have separate flex end point (remote object) to each session bean to invoke methods or to create a single facade session bean as an endpoint and invoke other session bean methods through this facade bean.
Whether creating multiple flex end points increases the performance or its an expensive process?
Creating a RemoteObject is not an expensive process but having many of them won't really increase client-side performance either. Typically all of your RemoteObjects will reference a shared ChannelSet which basically represents the connection to the server endpoint. I would recommend using one RemoteObject for each session bean you have. You can relate a RemoteObject to a session bean by specifying the "destination" property on the RemoteObject and ensuring that your server side implementation of the FlexFactory interface resolves the destination name to the appropriate session bean.

Resources