Isolation of EARs (and EJB3)

[Anonymous User]

Hi all,
I'm relatively new to EJBs and I'm trying to figure out how to deploy multiple instances of the same application to a JBoss application server. Each EAR will have its own context root, database, but will share the EJBs (entity and session) with all the other EARs. How should I layout my files?
Currently my EAR has a WAR file for the servlets, jsps, an EJB3 file for the entity and session beans, and two jar files which function as helper classes for the EJB and web tiers. My main problem so far has been the JBoss container complaining about duplicate deployments of EJBs, which is why I need to separate them out from the EAR files.

Has anyone successfully deployed multiple instances of a large, complex, EJB3 application and be willing to share some tips with me?

Thank you very much!

[Anonymous User]

I've been working on this by myself but I'm stuck. How would one package an application containing EJB3 entity beans, EJB3 stateless session beans, servlets and JSPs in such a way that multiple instances of the application can be deployed?

If I try to make each EAR file self-contained with JSPs/Servlets in a WAR, session/entity beans in an EJB3 archive, then the first EAR works but subsequent deployments in JBoss complain that the session beans already have been registered.

If I isolate the entity beans and remove them from the EAR, the EARs do not deploy because the session beans cannot find the entity bean classloaders.

If I isolate the entity and session beans, I then have trouble because each EAR cannot seem to find the correct datasource.

Does anyone have any advice? I've been stuck on this for a while now. Thanks!

[Roger Chung-Wee]

Why do you want to deploy multiple instances?

[Anonymous User]

Well, the application itself is an ECommerce app, and instead of creating multiple memory-intensive JBoss instances with one application on each, we figured it would be more efficient to run multiple instances of the same application on a single JBoss server. Each application would have its own context root, and hence can be mapped to a different domain with Apache. This way, we can host multiple "sites" from one single JBoss server.

[Roger Chung-Wee]

I am no JBoss expert, but I would think that you would need to edit several XML files to change the default port numbers for each instance.

[Mark Spritzler]

Yeah, it doesn't sound like you are getting anything out of having different .ears so to speak.

Why not just map the different URLs all to the same application, and have your EJB Pools contain enough of your EJBs to handle your traffic.

If you need more, you need to look at web farms, multiple servers, Load Balancers, those kind of tricks, not "Multiple instances of the same application" that just isn't needed.

Mark

[Anonymous User]

Thank you both very much for the feedback. The reason why we want different EARs is because we have different databases for each application. For example, two companies both purchase a license to use this application. They will not want to see each other's data.

I think it would be easier to install multiple instances of the application on one server, than to modify the software to dynamically switch databases on the fly since it is a very large EJB3 application. Such a modification will require changing over a thousand files.

Please let me know if you can think of any alternative to achieve the same results.

[Roger Chung-Wee]

Surely the switching of DBs is just a matter of pointing a DataSource to a different connection pool.

[Anonymous User]

The application I'm working on used to be EJB 2.0 BMP, where each bean had a getConnection() method which would allow switching of DBs on the fly.

We're currently upgrading it to EJB 3.0 CMP, but the dynamic switching of databases is a problem. I've tried asking for help on the JBoss forum here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=74456

Unfortunately, I've yet to receive any assistance. I'm still trying to figure out whether the problem is with the JBoss configuration, or if I don't completely understand the EJB3 persistence model. Meanwhile, I'm trying tangential methods such as deploying multiple applications, since that seems promising.

[Mark Spritzler]

Unfortunately, you are seeing first hand what happens and the huge cost of not doing it correctly up front. There should never had been a "getConnection" method in each and every Entity Bean. That is a very poor design. When designing, the number one thing to think about is how can this change, what would be the cost of the change, etc. There is more, but that doesn't help you now.

You guys should either 1. Bite the bullet, and remodel your application so that changes and things like this doesn't bite you in the *&^.

It looks like you just might have to go down the individual JBoss server for each database.

Mark

[Anonymous User]

Thank you very much for the responses so far, they have been very insightful.

We are actually in the process of completely remodelling the application right now. As I mentioned in my post, we're upgrading to EJB 3.0 CMP, where the database is specified in the persistence.xml file of the persistence unit (in our case, each .ejb3 archive).

However, my attempts to deploy identical ears with different persistence.xml configurations has failed. For some reason, each EAR is connecting to a default database in JBoss (DefaultDS) instead of connecting to the database specified in the persistence.xml configuration file.

So far I have managed to get two instances of the same application working, with different context roots and no JNDI conflicts, but I cannot seem to get each of them to connect to its own database.

[Mark Spritzler]

You should create DataSources for each database you want to connect, and have some configuration file for pointing "User Groups" to a particular DataSource, so that when any person logs onto your one application, not mutliple. Then it can easily look up the DataSource to use for that user. Then the user will use the correct DataSource for their "version" and your application is generic to use any DataSource.

Mark

[Anonymous User]

That's an interesting way to look at it. However, is that suggestion viable under EJB3? EJB3 accesses a database via an entity manager, which is injected into a context, usually a session bean. Each entity manager maps to a database. As far as I know, there is no simple way to "switch" the entity manager dynamically at runtime, which I believe is necessary if I am to choose a database upon user login.

I believe its possible to do a JNDI lookup of a dynamic entity manager at runtime, but such an approach means that every session bean method needs to be modified to lookup the entity manager, since the session beans are stateless. I keep thinking that if I could somehow get my EARs deployed in isolation... then it would be a relatively hassle-free way of fixing the problem. Is there a compelling reason not to pursue the isolated EAR solution?

[Roger Chung-Wee]

The DataSource, its binding to the JNDI tree and its relationship with a connection pool are fundamentally important to EJB, and it's no diferent in EJB 3.0. For EJB 3.0, each entity manager is specified and configured in a descriptor named persistence.xml, which must contain the necessary DataSource.

[Anonymous User]

Please help me out with this then: Below are two persistence.xml files which are each within an EJB3 archive within an EAR. Aside from this file, the contents of both EARs are identical. Am I missing anything?

<entity-manager>
 <name>ContextRoot1</name>
  <provider>org.hibernate.ejb.HibernatePersistence</provider>
  <jta-data-source>java:/DB1</jta-data-source>
  <non-jta-data-source>java:/DB1</non-jta-data-source>
<class>beans.entity.bean1</class>
<class>beans.entity.bean2</class>
  <properties>
 <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
 <property name="hibernate.hbm2ddl.auto" value="update"/>
 <property name="hibernate.connection.datasource" value="java:/DB1"/>
  </properties>
</entity-manager>

 
<entity-manager>
 <name>ContextRoot2</name>
  <provider>org.hibernate.ejb.HibernatePersistence</provider>
  <jta-data-source>java:/DB2</jta-data-source>
  <non-jta-data-source>java:/DB2</non-jta-data-source>
<class>beans.entity.bean1</class>
<class>beans.entity.bean2</class>
  <properties>
 <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
 <property name="hibernate.hbm2ddl.auto" value="update"/>
 <property name="hibernate.connection.datasource" value="java:/DB2"/>
  </properties>
</entity-manager>

The deployment scenario in which I've made the most progress is:
Two EAR files each with its own copy of:
1. a WAR (JSPs, Servlets)
2. a skeleton EJB3 archive which contains only a META-INF/persistence.xml and no classes
3. a helper JAR file.

Altogether, I deploy three items to JBoss at the same time. Both EARs, and a full EJB3 archive with only the entity and session classes and no persistence.xml.

Everything deploys without any problem. However, when I try to access either EAR from a browser, the datasource both end up connecting to is the default hypersonic database which comes built-in with JBoss.

Am I messing up on the persistence.xml deployment descriptors somehow?

I'm sorry if my questions are confusing. I'm only an intern trying to do all this

[Roger Chung-Wee]

A DataSource points to a connection pool which on start up creates a specified number of physical database connections. I don't know JBoss, but there will be a way to configure the pool and to associate the DataSource with a particular pool.