7 Replies Latest reply on Dec 14, 2004 8:36 PM by hariv

Read only lock

hariv Dec 14, 2004 8:36 PM

We have been using JBOSS for the last 3 years. I am having an issue with read-only entity beans in JBOSS 3.2.5 when there is heavy load . I have a set of entity beans all of them read-only , some of the them have a CMR relation ship. They all run in a cluster. I am getting a transaction time-out on some of the get methods when there is lot of traffic. All entity beans are cluster enabled. so they are using commit-option B behind the scences. Since the data cannot be changed , I set the commit-option to A and still have the same issue. I am not able to use transaction "NotRequired" because CMR forces me to have a transaction. My understanding is since I am using commit-option A , The entity bean should be always loaded from the cache, I have a doubt whether that is happening,because I can see the ejb load method getting invoked multiple times. I have read that even though a bean is set to read only,an instance of entity bean will be locked for the duration of the
method invocation. I will appreciate if you can explain why a read-only entity bean should be locked for the duration of the method and let me know a better way of using the cache and read only data,

1. Re: What's wrong with my XMBean?

hariv Dec 14, 2004 8:36 PM (in response to hariv)

If I uncomment the depends-list and comment the depends, jboss reports:

16:42:28,484 INFO [ConfigFile] Starting
16:42:28,500 ERROR [ConfigFile] Starting failed
javax.management.InstanceNotFoundException: jboss.mq:service=DestinationManager is not registered.
 at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:354)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:538)
 at com.smartcode.framework.config.server.config.mbean.ConfigFile.startService(ConfigFile.java:193)
 at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceInterceptor.java:59)
 at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInterceptor.java:43)
 at org.jboss.mx.interceptor.PersistenceInterceptor2.invoke(PersistenceInterceptor2.java:93)
 at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:75)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
 at $Proxy11.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:392)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy5.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy7.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:200)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:273)
 at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:392)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy5.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:597)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy6.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:365)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:272)
 at org.jboss.Main.boot(Main.java:150)
 at org.jboss.Main$1.run(Main.java:388)
 at java.lang.Thread.run(Thread.java:534)
16:42:28,500 WARN [ServiceController] Problem starting service com.s2.console.mbean:service=ConfigFile
javax.management.InstanceNotFoundException: jboss.mq:service=DestinationManager is not registered.
 at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:354)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:538)
 at com.smartcode.framework.config.server.config.mbean.ConfigFile.startService(ConfigFile.java:193)
 at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceInterceptor.java:59)
 at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInterceptor.java:43)
 at org.jboss.mx.interceptor.PersistenceInterceptor2.invoke(PersistenceInterceptor2.java:93)
 at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:75)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
 at $Proxy11.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:392)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy5.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy7.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:200)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:273)
 at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:392)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy5.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:597)
 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:324)
 at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy6.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:365)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:272)
 at org.jboss.Main.boot(Main.java:150)
 at org.jboss.Main$1.run(Main.java:388)
 at java.lang.Thread.run(Thread.java:534)
16:42:28,515 INFO [MainDeployer] Deployed package: file:/C:/jboss321/server/default/deploy/s2console.sar
...
16:42:39,062 ERROR [URLDeploymentScanner] MBeanException: Exception in MBean operation 'checkIncompleteDeployments()'
Cause: Incomplete Deployment listing:
Packages waiting for a deployer:
 <none>
Incompletely deployed packages:
 <none>
MBeans waiting for classes:
 <none>
MBeans waiting for other MBeans:
[ObjectName: com.s2.console.mbean:service=ConfigFile
 state: FAILED
 I Depend On:
 Depends On Me: javax.management.InstanceNotFoundException: jboss.mq:service=DestinationManager is not registered.]

Why?
Please tell me how I do it corretly, and please tell me what causes the diffenct result.

Thanks

I use jboss_3.2.1

2. Re: Read only lock

cryb Dec 16, 2004 3:57 AM (in response to hariv)

Hi there!
First of all... yes.. there is a preloaded cache but as far as I know this cache is per transaction. So when you come from another transaction to request access for the same row previously loaded by JBoss BUT in another transaction it will go again to database an start building a new preload cache for the new transaction.
Another issue is about locking... locking is performed 2 ways by JBoss: at JBoss level and at database level. At JBoss level you have optimistic/pessimistic containers and at database level you have the 4 transaction isolation levels defined by ACID properties. Moreover there are the 4 commit options of JBoss.
There is plenty to say... but if you want to understand what is happening you should document yourself on all this levels.
In the final, is normal to get a transaction timeout when there is a lot of traffic. Just try to increase the transaction timeout parameter in jboss-service.xml. Not that you can also change this parameter at a transactional method granularity using your application deployment descriptor jboss.xml.
Hope this will help you. Bye.
Actions
3. Re: Read only lock

aloubyansky Dec 17, 2004 4:45 AM (in response to hariv)

Lock is required for the method invocation because we operate on the persistence context (initialize it, load data, update data, etc).

What causes the timeout? Is it timeout to get an exclusive lock?
If so, you will have to use Instance Per Transaction with commit option C.
Or you could try http://www.jboss.org/wiki/Wiki.jsp?page=CMP2xJDBC2PM.
Actions
4. Re: Read only lock

hariv Dec 17, 2004 10:07 AM (in response to hariv)

Thanks for your reply Alex. CMP2xJDBC2PM is it available is JBOSS3.2.5.
The time out was for getting a transaction lock.

From your reply my understanding is , the container does'nt cache the entity bean instance, it just caches the data the entity bean represents. So the instance is locked ,for the duration of loading the data from the cache to the entity bean.

In my previous question I asked why ejbLoad is getting invoked multiple time for a read-only entity bean. Is it actually loading the data from the database or ejbLoad is loading data from the cache.

Thanks

Hari
Actions
5. Re: Read only lock

aloubyansky Dec 19, 2004 11:04 AM (in response to hariv)

The new persistence manager is in 3.2.5. But I would recommend at least 3.2.6 as there were valuable improvements in caching.

The container does cache instances in case of Standard container configuration. Plus there is read-ahead cache which a per-transaction cache.
Each invocation might change the persistence context either in business method or container internally by loading/initializing the instance.

You can set threshold to DEBUG for org.jboss.ejb.plugins.cmp category in log4j and see what SQL container executes. ejbLoad is not called if instance is cached. In other words, if instance is in the cache it is in the ready state.

I guess your instances are evicted from the cache due to reached maximum cache capacity or age out.
Actions
6. Re: Read only lock

hariv Dec 21, 2004 3:13 PM (in response to hariv)

Alex

Thanks for your reply. I changed the commit option to A in the standard jboss.xml and I could see ejbLoad not getting invoked for my read only entity bean . But I understand with commit option B the entity bean data is loaded during the start of every transaction.
I changed the transaction attribute for all the methods to NotSupported even then I could see ejbLoad getting invoked . My understanding is for transaction attribute NotSupported ,even with commit option B, since there is no transaction the container should use the data from the cache (should act like A).
Actions
7. Re: Read only lock

aloubyansky Dec 28, 2004 3:47 AM (in response to hariv)

In JBoss, instances that are in the container with commit option B will always be loaded before each method invocation if the invocation is not transactional. Accessing entity beans w/o a transaction is not recommended by the spec and by us.
Actions

Go to original post