Same datasource in multiple ear applications

[connerjohn]

I have the same datasource that is accessed from mutliple Seam applications (ears). I am getting an error on the second application that is deployed telling me that the datasource has already been deployed.

What do I need to do (not do?) so that I can run the same datasource in multiple seam ear applications. Is this a fatal error, or can I safely ignore it and both applications will use the same datasource?

Or do I need to create a distinct datasource for each application (the datasources will be the same except for the name them as both applications hit the same database/tables).

Or is it the name of the persistent unit as indicated by the exception below the issue. This will be tricker to make unique across applications as the applications share code that access the persistent unit based on its name (em).

I am using the same persistence.xml file in a jar file loaded into each *.ear file:

<persistence>
 <persistence-unit name="em">
 <provider>org.hibernate.ejb.HibernatePersistence</provider>
 <jta-data-source>java:/itsDatasource</jta-data-source>
 <properties>
 <property name="hibernate.show_sql" value="false"/>
 <!-- These are the default for JBoss EJB3, but not for HEM: -->
 <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/>
 <property name="jboss.entity.manager.factory.jndi.name" value="java:/itsEntityManagerFactory"/>
 <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
 </properties>
 </persistence-unit>
</persistence>

The datasource file (prod-ds.xml) loaded in the jboss deploy directory is:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
 <local-tx-datasource>
 <jndi-name>itsDatasource</jndi-name>
 <connection-url>jdbc:mysql:///LMS?useServerPrepStmts=false</connection-url>
 <driver-class>com.mysql.jdbc.Driver</driver-class>
 <user-name>username</user-name>
 <password>password</password>
 <max-pool-size>50</max-pool-size>
 </local-tx-datasource>
</datasources>

Thanks
--jc

Here is the error message:

15:56:06,281 WARN [ServiceController] Problem starting service persistence.units:ear=shop-local.ear,jar=shop-local.jar,unitName=em
javax.naming.NameAlreadyBoundException
 at org.jnp.server.NamingServer.bind(NamingServer.java:144)
 at org.jnp.interfaces.NamingContext.bind(NamingContext.java:566)
 at org.jnp.interfaces.NamingContext.bind(NamingContext.java:531)
 at org.jboss.ejb3.NonSerializableFactory.bind(NonSerializableFactory.java:94)
 at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:278)
 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.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:99)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy201.start(Unknown Source)
 at org.jboss.ejb3.JmxKernelAbstraction.install(JmxKernelAbstraction.java:82)
 at org.jboss.ejb3.Ejb3Deployment.startPersistenceUnits(Ejb3Deployment.java:626)
 at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:475)
 at org.jboss.ejb3.Ejb3Module.startService(Ejb3Module.java:139)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy36.start(Unknown Source)
 at org.jboss.ejb3.EJB3Deployer.start(EJB3Deployer.java:449)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
 at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
 at org.jboss.ws.server.WebServiceDeployer.start(WebServiceDeployer.java:117)
 at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
 at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy37.start(Unknown Source)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
 at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy6.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy4.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy5.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
 at org.jboss.Main.boot(Main.java:200)
 at org.jboss.Main$1.run(Main.java:464)
 at java.lang.Thread.run(Thread.java:595)

[connerjohn]

Little more information if this will help. When I deploy application1.ear (actually name is back-local.ear), no errors and everything runs correctly.

When I deploy application2.ear (shop-local.ear) and app1 is already deployed, I get the following error. However, I can still access my application and things do not appear to be affected.

If I just deploy app2 without app1 being deployed already, there are no execptions and everything works correctly.

I can post more of the log or different configuartion files if needed.

--jc

[connerjohn]

ok - last piece of information and I'm out of ideas:

Also, I am runing the latest EJB JEMS and the latest CVS Seam.

When I go look at jmx-console I find two persistent unit listed:
* ear=backoffice-local.ear,jar=backoffice-local.jar,unitName=em
* ear=shop-local.ear,jar=shop-local.jar,unitName=em

Here are the details for both and the shop-local deployment failed:

List of MBean attributes:
Name Type Access Value Description
StateString java.lang.String R Started MBean Attribute.
State int R 3 MBean Attribute.
Name java.lang.String R ServiceDelegateWrapper MBean Attribute.

List of MBean attributes:
Name Type Access Value Description
StateString java.lang.String R Failed MBean Attribute.
State int R 4 MBean Attribute.
Name java.lang.String R ServiceDelegateWrapper MBean Attribute.

[connerjohn]

I've looked around a bit more; but haven't found anything. It seems like I shoud be able to deploy the same persistent.xml in different ears files.

Any thoughts?

--jc

[alrubinger]

<persistence-unit name="em">

The name there's gotta be unique :/ Everything else in your persistence.xml can remain the same, and you may use just the one DS file.

If you'd like to only have one instance of your persistence.xml file, consider repackaging such that both of your Seam apps will have access to it...

S,
ALR

[connerjohn]

"ALRubinger" wrote:

If you'd like to only have one instance of your persistence.xml file, consider repackaging such that both of your Seam apps will have access to it...

ALR,

Thanks for the information. I didn't realize that the persistence unit name had to be unique across ears. I assumed that the names would be localized to the namespace of each individual ear application. I wanted to use Seam and am learning a whole lot about applications servers in the process.

What would you recommend I do for "repackaging". Just create another ear file with the bare minimum to load the persistence unit into the JNDI session? Or is their something else I should consider.

Thanks,
--jc

[alrubinger]

Yep; you can see the entry for your persistence.xml name in the JMX Console under the heading "persistence.units"...

As far as repackaging - you have a couple options:

Deployment Isolation - Every archive into your deploy directory exists in its own little bubble with its own classloader. Classes in one application won't be available to another.

Flat Deployment - All archives in your deploy directory use a shared classloader, making classes deployed from one app available to another. The drawback here is in a classloader's "first one loaded wins" principle, and you won't be able to support different versions of the same package - plus it's VERY hard to debug. For instance, assuming you have your 2 WARs, each one containing different versions of the Seam libraries. You might start to see in one of the WARs unexpected results in the form of MethodNotFoundExceptions or worse - different behaviour than when deployed on its own. You have to be very careful about not overlapping versions of classes when using flat deployment.

These articles explain it much better and in greater detail than I'm capable:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases

Also, JBoss supports "Russian Doll" packaging, where any type of archive can be packaged into any other type of archive (eg. a WAR in an EAR in a JAR)...so as long as your aware of where your classes are, where they'll be available; the details are up to you.

S,
ALR

[alrubinger]

Oh, the notes above are operating under the assumption that you have shared code/libraries in your Seam apps that you might like to externalize. The Persistence Unit should be available to all of your apps once deployed regardless of the deployment isolation type selected.

[bill.burke]

"connerjohn" wrote:

"ALRubinger" wrote:

If you'd like to only have one instance of your persistence.xml file, consider repackaging such that both of your Seam apps will have access to it...

ALR,

Thanks for the information. I didn't realize that the persistence unit name had to be unique across ears. I assumed that the names would be localized to the namespace of each individual ear application. I wanted to use Seam and am learning a whole lot about applications servers in the process.

What would you recommend I do for "repackaging". Just create another ear file with the bare minimum to load the persistence unit into the JNDI session? Or is their something else I should consider.

Thanks,
--jc

It should be localized. if it is not, there is a problem.

[bill.burke]

This is what has to be unique:

 <property name="jboss.entity.manager.factory.jndi.name" value="java:/itsEntityManagerFactory"/>

The unit name does not have to be unique between EARs.

Why is this happening? the jboss.entity.manager.factory.jndi.name binds to global JNDI.

[connerjohn]

This is what has to be unique:

 <property name="jboss.entity.manager.factory.jndi.name" value="java:/itsEntityManagerFactory"/>

The unit name does not have to be unique between EARs.

Why is this happening? the jboss.entity.manager.factory.jndi.name binds to global JNDI.

Ok - so after thinking about this for a while and walking the Seam examples and my applications, I believe I see what you are talking about. I need to set the jndi name for each persistent unit (the property you highlighted) to be unique across the ear applications.

To reiterate for myself, the reason is that the jndi name needs to be unique across the application server instance. I am getting the exception because both applications are trying to bind to the same jndi name. And that is why one "failed" to deploy; yet the application still worked (it found the other one that was previously deployed).

I will try that out tomorrow. I'm sure it's a cut/paste issue. I followed the Seam examples and then copied my skeleton to new applications without realizing this property also needs to be changed. And since I don't have enough experience with an application server, I'm not sure I every would have figured this out.

Thanks for looking at this,
-- jc

[alrubinger]

This is what has to be unique:

 <property name="jboss.entity.manager.factory.jndi.name" value="java:/itsEntityManagerFactory"/>

The unit name does not have to be unique between EARs.

Stand very corrected.

S,
ALR

[apill]

Is there any way to bind the jndi name to a scope localised to the ear it is within?

[apill]

Or, instead of doing the following...

@PersistenceContext(unitName="myUnit")
EntityManager em;

can I look up the EntityManager from within a session bean by its persistence-unit name instead of via its jndi binding name?

Thanks.
Adrian