We had to set all our beans to Requires New but this will not work if you don't have all read only beans..
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.
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.
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 ...
Won't you still get dirty reads this way?
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.