I am a newby with CDI and EJB and I've just created a jboss web application. Though, additionally, I also wanted this app to process rabbitmq messages. When processing these, I would like to do some persistence work, though, as I've been listening for rabbitmq messages from an application scoped bean that is started with the #Startup annotation, I've not been able to commit any transaction within this kind of scope, that is, as I am departing from the application scope, every bean that I will instatiate from this scope will be application scoped. When I try to perform em.getTransaction() and em.commit() the code blows up complaining that I cannot invoke getTransaction() under JTA transactions, and when I use User transactions, every operation seems to be put onto the same transaction until it finally is rolled back, or there errors complaining that there is a already a transaction underway...
CDI beans do not support transactions out of the box like EJBs do. So your options are to either:
Upon receiving RabbitMQ messages, call some EJBs (directly or through observers) that will do the persistence work.
Add transactions support to your existing CDI beans using one of the following - Apache DeltaSpike or Seam Persistence.
It is indeed quite hard to give you more details based on the info you provided. However, on the conceptual level, one of the approaches above would do the trick.
Also, the notion of event scope seems confusing. I would say you don't need it. One of the approaches above will do. Also, take a look at CDI events.
Related
I am reviewing my code from since I picked up on JSF.
One of the most complex issues has come up once again. The decision between CDI and EJB.
I am using three layers and I wonder which type of annotation to use on each of them:
- Backing beans (the Controller as defined in MVC)
- The service layer
- DAO's
My backing beans are using CDI, as long as I don't need anything from EJB.
But I am stuck on those other two. I remember reading about using EJB beans because of the pooling functionalities, which would prevent massive loads of requests (or attacks, if you will).
So in short, is there ANY reason to use EJB (Stateless, Stateful, LocalBean et cetera), considering security or anything else (excluded ViewScoped)?
Thanks in advance.
You're making a conceptual mistake here. CDI is absolutely not an alternative to EJB. CDI in its default trim doesn't offer transaction management at all. CDI is a bean management and dependency injection API, not a service layer API. In order to manage transactions in CDI, you've to add another API along with a bunch of another annotations.
CDI can replace for example JSF managed bean annotations, but definitely not EJB annotations.
So there's no means of a valid "CDI vs EJB" question. Both have their own completely distinct purposes. Note that you can perfectly inject EJB based service classes in CDI based managed bean classes.
As to security, it's not clear why you mentioned that part in the title and the tags, but the decision between CDI and EJB has nothing to do with security (simply because there's no means of a valid "CDI vs EJB" question in first place).
Yes when you require out-of-box support for transactions, concurrency, pooling etc.
The new JSR 299 "Contexts and Dependency Injection for Java EE" seems to be based on the concept of "Scope".
The beans are created and associated to one of the supported Scopes: Application, Session (mapped to a HTTP session), Conversation, and Request.
Does it make sense to use CDI if there is no HTTP Session (for example, an Enterprise application that exposes functionality through EJBs remoting) since the Managed Beans are not going to be associated to any Context (since they do not exist)?
Is it even possible to use CDI in such an scenario? Which advantages would it bring to it?
It reminds me of my own question I asked some time ago: How does #SessionScoped work with EJB? Is CDI only for web-tier?
It seems that the idea of 'scope' is relevant only in the case of HTTP Session.
However, I can see a valid use of the #ApplicationScoped scope as a way to implement an application-singleton bean, despite if the request is a HTTP one.
Javadoc says:
The application scope is active:
(...)
during any Java EE web service invocation,
during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB
timeout method and during message delivery to any EJB message-driven
bean,
You can also create your own scopes. CDI is very extensible and can be used in a variety of situations. It's also being used in SE applications where there is neither an HttpSession nor HttpRequest.
Apart from that, CDI is not only for Lifecycle managment, you can use it to do dependency injection thus separating interfaces from their implementations in a very clean way. You can also perform some AOP techniques using interceptors and decorators, or build a very loose-coupled Observer pattern by taking advantage of CDI Events.
I am currently having a problem with understanding a concept of JPA.
I am currently using/developing recent EclipseLink, Glassfish, Derby database to demonstrate a project.
Before I develop something in much bigger picture, I need to be absolutely sure of how this PersistingUnit work in terms of different scopes.
I have bunch of servlets 3.0 and currently saving user's associated entity classes in the request.session object (everything in the same war file). I am currently using Application-managed EntityManager using EntityManagerFactory and UserTransaction injection. It works smooth when it is tested by myself. The different versions of entities occur when 2 people accessing the same entities at the same time. I want to work with managed beans cross the same WAR, same persistence unit if possible.
I have read http://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html and bunch of explanations of those scopes which don't make sense at all for me.
Long story short, what are the usage and difference of app and container managed EntityManagers?
When you say application managed transaction it means its your code which is supposed to handle the transaction. In a nutshell it means:
You call:
entityManager.getTransaction().begin(); //to start a transaction
then if success you will ensure to call
entityManager.getTranasaction().commit(); //to commit changes to database
or in case of failure you will make sure to call:
entityManager.getTransaction().rollBack();
Now imagine you have a container, which knows when to call begin(), commit() or rollback(), thats container managed transaction. Someone taking care of transaction on your behalf.
You just need to specify that.
Container managed transaction(CMT) could be regarded as a kind of declarative transaction, in which case, transaction management is delegated to container (normally EJB container), and much development work could be simplified.
If we are in a Java EE environment with an EJB container, we could use CMT directly.
If we are in a Java SE environment, or a Java EE environment without an EJB container, we could still take advantage of CMT, one way is to use Spring, which uses AOP to implement declarative transaction management; Another way is to use Guice, which uses a PersistFilter to implement declarative transaction.
In CMT, a container (whatever an EJB container, Spring or Guice) will take care of the transaction propagation and commit/rollback stuff;
Application managed transaction (AMT) differs from CMT in that we need to handle transactions programmatically in our code.
I am planning an application that must provide services that are very much like those of a Java EE container to third party extension code. Basically, what this app does is find a set of work items (currently, the plan is to use Hibernate) and dispatch them to work item consumers.
The work item consumers load the item details, invoke third party extension code, and then if the third party code did not fail, update some state on the work item and commit all work done.
I am explicitly not writing this as a Java EE application. Essentially, my application must provide many of the services of a container, however; it must provide transaction management, connection pooling and management, and a certain amount of deployment support. How do I either A) provide these directly, or B) choose a third party library to provide them. Due to a requirement of the larger project, the extension writers will be using Hibernate, if that makes any difference.
It's worth noting that, of all of the features I've mentioned, the one I know least about is transaction management. How can I provide this service to extension code running in my container?
Hi I recommend using the Spring Framework. It provides a nice way to bring together a lot of the various services you are talking about.
For instance to address your specific needs:
Transaction Management/Connection pooling
I built a spring-based stand-alone application that used Apache commons connection pooling. Also I believe spring has some kind of transaction mgmt built in.
Deployment support
I use ant to deploy and run things as a front-loader. It works pretty well. I just fork a seperate process using ant to run my Spring stand-alone app.
Threading.
Spring has support for Quartz which deals well with threads and thread pools
DAO
Spring integrates nicely with Hibernate and other similar projects
Configuration
Using its xml property definitions -- Spring is pretty good for multiple-environment configuration.
Spring does have transaction management. You can define a DataSource in your application context using Apache DBCP (using a org.apache.commons.dbcp.BasicDataSourceorg.springframework.jdbc.datasource.DataSourceTransactionManager for the DataSource. After that, any object in your application can define its own transactions programatically if you pass it the TransactionManager, or you can use AOP interceptors on the object's definition in your application context, to define which methods need to be run inside a transaction.
Or, the easier approach nowadays with Spring is to use the #Transactional annotation in any method that needs to be run inside a transaction, and to add something like this to your application context (assuming your transactionManager is named txManager):
<tx:annotation-driven transaction-manager="txManager"/>
This way your application will easily accept new components later on, which can have transaction management simply by using the #Transactional annotation or by directly creating transactions through a PlatformTransactionManager that they will receive through a setter (so you can pass it when you define the object in your app context).
You could try Atomikos TransactionsEssentials for Java transaction management and connection pooling (JDBC+JMS) in a J2SE environment. No need for any appservers, and it is much more fun to work with ;-)
HTH
Guy
I'm mantaining a EJB 2 CMP legacy app runing on a JBoss 4.0.4 GA application server with deployed entity/stateless session beans. All the EJB boilerplate code is generated via XDoclet from the EntityEJB/EntityEJBManager annotations.
I've noticed that when my GUI client invokes the facade create method, I have lots of cases of EJBException in my server log with the "Reentrant method call detected" message, which rollbacks the transaction.
What does this Exception means? How can I avoid having such error (which unfortunately, I wasn't able to reproduce yet)
Update: Found this link that explains what is meant by reentrancy, however, seems to me that it says my app cannot be accesed concurrently?
I've seen this before where EJB1 calls EJB2 which calls back to EJB1 within the container as part of the same transaction.
You can tell the container to allow this by marking EJB1 as reentrant which will allow it to be accessed multiple times in the same transaction.
This is done in the deployment descriptor with the following tag:
<reentrant>True</reentrant>
There should be a corresponding EntityEJB annotation that XDoclet can use to generate this for you.
we just came across the same problem and our solution was two-fold. Firstly we ensure that none of ejb's had transaction attributes of NotSupported within our ejb-jar.xml. We then used "instance per transaction" as our optimistic locking strategy. It's a bit of a belt-and-braces approach, but it works
It does mean that the Entity bean in question cannot be accessed concurrently, which makes sense since it would likely corrupt the data.