Pessimistic Locking (sigh) ...

[binaryfeed]

We're currently using JBoss 2.4.0 FINAL for our product. Our product is not a typical web application, in that we have several transactions that are "long running". That is, some transactions are on the order of 5-40 minutes. In case you were wondering, there is *NO* user interaction in the middle of a transaction.

Though we do have several long-running transactions, we also have the usual read-only operations, as well as some short-lived transactions.

JBoss deadlocks for us under "normal" usage. That is, 3-10 users logged on kicking off some long-lived methods with "Required" transactions, some short-lived methods with "Required" transactions and some read-only methods with "Supports" transactions.

We've tried both Commit Option A and Commit Option B with virtually no difference in deadlock occurrence.

I've read on these forums that many people are using JBoss for heavy-load production sites. How do you deal with the pessimistic locking issue? Or, is our application unique in that it has some long-running transactions? Will switching to something like CocoBase / TopLink / ObjectMatter / Castor help with this issue?

Please help! Right now, we've put a "hack" into our code that is serializing all method invocations on the server to a single thread. :-(

[thedug]

We had to set all our beans to Requires New but this will not work if you don't have all read only beans..

d.

[davidjencks]

What exactly do you mean by deadlock? Do all threads stop because they are interfering with each other or do your user threads stop and time out because the long running transactions are consuming all resources?

Note that if the long running transaction uses a particular entity bean (corresponding say to a particular db row) no other transaction can access it until the long running transaction commits. One way to get around this (at a possible cost of doubling data caching) might be to deploy your entity beans twice under two names, one for short transaction use, one for long transaction use.

There is also a problem, at least using the jca framework, in the connection pooling. Under high load, one request for a connection can wait essentially forever, while many other newer requests get connections. I don't know if this could explain your problems.

[thedug]

Another solution that we just discovered is setting the session beans to BMT and then letting jboss handle the entity beans. You still need to make sure that your entity beans are always called in the same order.

[binaryfeed]

Well, here's what we're *TRYING*. I'll send a follow-up post letting you know whether or not it worked.

In the deployment descriptors for our entity beans, we duplicated each entity bean with another "read-only" version of the entity bean. All of the transaction attributes for these new read-only beans are set to RequiresNew.

In the entity bean implementations, if a write method is attempted on a read-only bean, we throw an exception.

In the session beans using the entity beans, we just get a handle to the read-only bean instead of the standard writable one, unless we're doing writes.

Let's hope it works ...

[thedug]

Won't you still get dirty reads this way?

[davidjencks]

I think it depends on what you mean by dirty read and whether you think read committed is consistent with the I in ACID. Everything he sees with a "read-only" bean will have been committed by some transaction. However, just as with read-committed, he won't get a consistent view of the data. As far as I know the only way to get a consistent view with reasonable performance is to use a versioning database such as firebird/interbase.