TRANSACTION_READ_UNCOMMITTED (Dirty-Read) doesn't work...

[semi]

Hi,

can anybody point me to the right solution in the following situation?

- There is an EntityBean (BMP) accessed in two transactions.
- Both of them are started from different clients. (through a SessionFacade)

Transaction A: Iterates through Records 1 ... 1000 and does some validation stuff. (validation-batch)
Transaction B: Executes few Insert- or Delete-Statements. (import-batch)

Transaction B does not change any of the rows accessed within transaction A!!!
While Transaction A is running, Transaction B is blocked. Why?
The Bean is in a Container with CommitOption A and there is TRANSACTION_READ_UNCOMMITTED in the Datasource-Deployment

Thanks,
Michael

[juha]

Default pessimistic locking for an entity bean. A owns a transactional lock on entity instances it accesses within the transaction. B is queued on lock acquire until A commits.

There are couple of ways to increase concurrency (throughput) at the entity level, one of the most obvious is marking some methods on your beans as read-only. See the jboss.xml DTD for details.

Isolation level is not related to entity bean locking, it only serves as an indication to the database what isolation level the JDBC connection expects.

HTH

[semi]

Thanks for the answer,

Default pessimistic locking for an entity bean. A owns a transactional lock on entity instances it accesses within the transaction. B is queued on lock acquire until A commits.
That's OK as long both transactions access the same Entities (rows in the database)
My problem are not transactions accessing the same records.

There are couple of ways to increase concurrency (throughput) at the entity level, one of the most obvious is marking some methods on your beans as read-only. See the jboss.xml DTD for details.
All my "readonly"-Methods are marked as readonly in jboss.xml.
I do it as follows:

<method-attributes>
 <method>
 <method-name>get*</method-name>
 <read-only>true</read-only>
 </method>
 <method>
 <method-name>is*</method-name>
 <read-only>true</read-only>
 </method>
 <method>
 <method-name>has*</method-name>
 <read-only>true</read-only>
 </method>
</method-attributes>

Let me explain it as follows:

Transaction A

createRecords(1....1000)
removeRecord(1...1000)

Transaction B

createRecords(1001....2000)
removeRecord(1001...2000)

The transaction which is executed first does it's job as expected.
The other one is blocked until the first is finished.

Do you have an idea how to let them run at the same time?

Regards,
Michael

[juha]

In that case there should not be lock conflicts at the app server level. What is the locking on your DB table in case of INSERT and DELETE ?

[semi]

Hi,

the database has no "table-lock" while inserting or deleting records. we tested it, using JDBC-only.
It must be something related to the container settings.

Maybe the org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock?

Do you have an working standardjboss.xml, which does not lock tables, when accessed from within different transactions?
Our Container configuartion looks like this:

<container-configuration>
 <container-name>Standard BMP EntityBean</container-name>
 <call-logging>false</call-logging>
 <invoker-proxy-binding-name>entity-rmi-invoker</invoker-proxy-binding-name>
 <sync-on-commit-only>false</sync-on-commit-only>
 <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
 <container-interceptors>
 <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
 <interceptor metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityCreationInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntityReentranceInterceptor</interceptor>
 <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor>
 </container-interceptors>
 <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
 <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
 <persistence-manager>org.jboss.ejb.plugins.BMPPersistenceManager</persistence-manager>
 <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
 <container-cache-conf>
 <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
 <cache-policy-conf>
 <min-capacity>50</min-capacity>
 <max-capacity>1000000</max-capacity>
 <overager-period>300</overager-period>
 <max-bean-age>600</max-bean-age>
 <resizer-period>400</resizer-period>
 <max-cache-miss-period>60</max-cache-miss-period>
 <min-cache-miss-period>1</min-cache-miss-period>
 <cache-load-factor>0.75</cache-load-factor>
 </cache-policy-conf>
 </container-cache-conf>
 <container-pool-conf>
 <MaximumSize>100</MaximumSize>
 </container-pool-conf>
 <commit-option>A</commit-option>
 </container-configuration>

Thanks,
Michael

[demarco]

Yes, we have got the same Problem. Using JBOSS 3.0.0 same Configuration. Is there someone, who can help?