I'm afraid that the method-attributes element is in jboss_3_1.dtd.
That must be a mistake.
The code for read-only methods was added before
the 3.0.0RC1 release
> That must be a mistake.
Could you tell me how we can use the usuful feature with JBoss 3.0.x?
I wonder we could drop the dtd declaration from jboss.xml or use jboss_3_1.dtd instead.
I found the answers to my questions about deadlocking in the JBoss Administration and Development Book. Chapter 5 of this book covers the topic in detail. If anyone else is having problems with deadlocks, I highly recomend getting that book and reading chapt. 5.
Basically I created a configuration that uses commit option a and <read only> tag for my read only beans and used the instance per transaction method for my write beans (which seems a lot like optimistic locking). Anyway, the deadlocks are gone and performance looks excellent so far.
One thing I have yet to explore is the option to make methods readonly. Not sure exactly how this works by my understanding is that if you have a mostly read -only bean you can go with commit option a, pesimistic locking and make all the getters read-only, which will prevent the object from locking until you do a write.
One thing I don't understand is why the default options of jboss are set with the pessimistic locking on reads. It seems like any application that has any sort of volume would experience tons of deadlocks with the default config.
Deadlocks are an ordering problem. Sometimes
they can't be avoided.
3.0.5 will include automatic retries of deadlocked
transactions (up-to 5 times).
read-only methods work like a RequiresNew transaction
except within the same transaction.
The lock is released on return from the method,
without waiting for whole transaction to commit.
Imagine Thread 1 does
Thread 2 then does
Thread 1 now uses "value", it is out-of-date without
Hence pessimistic is the default.
The principal of no suprises.