local entities mapping incorrectly between ejb containers in

[kivilahti]

Hi. I have a strange problem with an application with two ejb containers (each in its own jar) in one ear. We're using JBoss and MVCSoft. This problem has manifested itself at least on JBoss versions 3.0.7, 3.2.0 and 3.2.1. I've contacted MVCSoft and it seems that the bug is not theirs.

Each of the ejb jars contain an entity bean set which is generated from the same source code. One has read-only entities, the other has read-write entities. EJB names are similar, JNDI names are different. The containers do not need to access each other's beans, but I need to be able to cache the read-write entities (performance issues). I also must be able to run these containers in one ear.

In about 50% of the times I redeploy the ear, I get read-only beans in the read-write container and the application starts throwing transaction rollback exceptions with "Read only entity" messages. After that, I need to restart JBoss to get rid of the exceptions. Application redeploy is not enough. This happens even if I redeploy the exact same ear. After restart, everything seemingly works again.

But I've noticed that even when the application does not throw read-only rollbacks, read-only cache does not seem to be in use. I get throusands of entries in the MVCSoft database log, where there should be only a few. I also get pessimistic lock exceptions from concurrent use, even though the read-only beans have been configured to use optimistic locking. This would suggest that each time there is only set of entity beans in use?

Could the unified classloader be causing this, or could it be because of the similar ejb names? Any suggestions are welcome.

We have run this application on WebSphere with no problems.

[adrian.brock]

Post your jboss.xml, it sounds like it is not being
read correctly.

Regards,
Adrian

[kivilahti]

Descriptors are generated with XDoclet. I cropped examples of one entity and one session bean in each descriptor.

Read-write container's jboss.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.0//EN" "http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd">



<enterprise-beans>


<ejb-name>fe/data/FooBar</ejb-name>
<local-jndi-name>fe/data/FooBar</local-jndi-name>
<configuration-name>Standard BMP EntityBean</configuration-name>




<ejb-name>fe/EventProcessor</ejb-name>
<jndi-name>fe/EventProcessor</jndi-name>


</enterprise-beans>

<resource-managers>
</resource-managers>



And read-only container's jboss.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.0//EN" "http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd">



<enterprise-beans>


<ejb-name>fe/data/FooBar</ejb-name>
<local-jndi-name>fe/ro/FooBar</local-jndi-name>
<configuration-name>Instance Per Transaction BMP EntityBean</configuration-name>



<ejb-name>fe/FooBarLookupService</ejb-name>
<jndi-name>fe/FooBarLookupService</jndi-name>


</enterprise-beans>

<resource-managers>
</resource-managers>

[adrian.brock]

Instance per transaction is not "read-only".

Can you post the stacktrace of the error message? Since this
is BMP and a don't see a <read-only> declaration in jboss.xml
I suspect you are generating this message?

Regards,
Adrian

[kivilahti]

We're using MVCSoft to generate the BMP beans. Read-write entity beans are generated with CommitOptionA and read-only entity beans with read-only. These beans are the ones that throw the final rollback exceptions.

I'll post the stack trace as soon as I'm back in the office.

[kivilahti]

Ok, here's what I think is the relevant part of the stack trace. After this, a TransactionRolledbackException is thrown with an identical stack trace.

13:34:32,383 ERROR [LogInterceptor] TransactionRolledbackLocalException, causedBy:
java.lang.IllegalStateException: Read only entity.
at com.quartal.fe.mvc.lookup.fe_data_FooBar106180154697473451499.setEndTime(fe_data_FooBar106180154697473451499.java:153)
at com.quartal.fe.ejb.AbstractFooBarBean.setEndTime(AbstractFooBarBean.java:81)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1194)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:303)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:90)
at org.jboss.ejb.plugins.EntityMultiInstanceInterceptor.invoke(EntityMultiInstanceInterceptor.java:112)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:301)
at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy338.setEndTime(Unknown Source)
at com.quartal.fe.storage.ejb.FooEventProcessorImpl.updateFooBar(FooEventProcessorImpl.java:340)
at com.quartal.fe.storage.ejb.FooEventProcessorImpl.processFooEvent(FooEventProcessorImpl.java:131)
at com.quartal.fe.storage.ejb.FooEventProcessor.processFooEvent(FooEventProcessor.java:50)
at com.quartal.fe.storage.ejb.EventProcessorBean.processFooEvent(EventProcessorBean.java:226)
at com.quartal.fe.storage.ejb.EventProcessorBean.processEvent(EventProcessorBean.java:163)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke(Container.java:738)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:99)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:111)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76)
at $Proxy332.processEvent(Unknown Source)
at com.quartal.fe.storage.ejb.EventProcessorImpl.processEvent(EventProcessorImpl.java:125)
at com.quartal.fe.event.EventProvider.processEvent(EventProvider.java:163)
at com.quartal.fe.event.EventProvider.onMessage(EventProvider.java:148)
at com.quartal.fe.event.EventProvider.receive(EventProvider.java:116)
at com.quartal.fe.event.EventProvider.access$500(EventProvider.java:40)
at com.quartal.fe.event.EventProvider$ReceiverThread.run(EventProvider.java:275)

[adrian.brock]

And where is this class deployed when it goes wrong?
This isn't metadata, it is in this generated class.

com.quartal.fe.mvc.lookup.fe_data_FooBar106180154697473451499

Is it the correct class?

Regards,
Adrian

[kivilahti]

Yes, that class throws the exception. It should be deployed in the read-only container. At least its class and descriptors are in the read-only container's jar. The EventProcessor session bean is in the read-write container and should only have access to read-write entity beans. So where does the mix-up between these two containers happen, is my concern.

When I look the at jmx-console, under "jboss.management.single" I see two sets of deployed entities within the ear, each in its respective EJBModule. Likewise, I see two sets of entities under "jboss.j2ee". But I haven't noticed any way to find out the mappings between these two, ie. what ejb-names are mapped to what jndi-names in runtime. So I don't know how to answer your question except by saying "should be in the read-only container". I may be missing something obvious here.

Jmx-console views are exactly the same when the application throws rollbacks and when it doesn't.

Is placing the bean classes and xml descriptors in separate jars really enough to place them in separate ejb containers?

The stack trace made me think first that this was an MVCSoft problem, but since then I have been in contact with MVCSoft and it seems that the generated classes and descriptors are ok. So (to my limited knowledge) this looks like some kind of naming context problem. I was hoping this was some kind of an easy JBoss configuration issue, which I've just failed to notice.

Whether or not this must eventually be solved by refactoring the ejb containers into one just to get forward with the project, I must thank you for your patience. I'd really hate to lose JBoss as our development and production platform, so I appreciate all help.

[adrian.brock]

Why would it be a naming problem?
You mapped the ejbs to different jndi names and each
jar has its own ENC.

How are you retrieving the beans, global jndi or java:comp?

I really need to see more information. I don't recognise
any the symptoms.

You should be able to see the jndiname inside jboss if you ask
the entity context for the EJBObject and toString() it.
You can also then do getClass().toString()

I would doubt it is a naming problem unless the descriptors
are wrong. Which would suggest a packaging problem
(i.e. wrong descriptor in the wrong jar) if they are autogenerated.

Regards,
Adrian