As far as locking mechanimsms go, I really don't think one size fits all. I
think it would be very useful for JBoss to have different pluggable locking
mechanisms for entity beans and a well documented cookbook on when to use
each one. This email is my first stab at establishing some requirements of
which I'll start implementing from when I have some free time here and
there. I'd really appreciate input from people more expert in this area.
Solutions for Commit Option A:
* classic jboss locking
Advantages:
1. Doesn't rely on datastore for locking
Disadvantages:
1. Complex code
2. Useless in "clustered" environment (unless some distributed locking
mechanism is written.
3. <flameRisk>Still buggy after all these months.</flameRisk> Please don't
take this personally....
* select-for-update (in the abstract sense)
Advantages:
1. Greatly simplifies entity container in JBoss. We can rip out a lot of
code and this will probably be more reliable and robust.
2. Useful in a "clustered" environment. (Our app uses it to synch multiple
instances of JBoss running on different machines)
Disadvantages:
1. Non-portable. Not supported by all datastores.
2. Is the Container responsible for synchronization in BMP or is the Bean
Developer responsible?
* optimistic locking
Advantages:
1. High performance
2. Portable
Disadvantages:
1. Not the best solution for entities that are NOT read-mostly. In fact, it
may decrease performance for entities that are read/write 50/50 or
write-mostly.
2. It may not be acceptable in a lot of apps for an exception to be thrown
on an optimistic lock failure.
--------------------------------------------------------
Solutions for Commit Option B and C:
* classic jboss locking
Advantages:
1. see above
Disadvantges:
1. see above
2. Plus, there is no reason to transactionally lock an entity it just hurts
performance.
* optimistic locking
Advantages/Disadvantages: same as above.
* multiple instances (instance per transaction can be synched by select for
update or TransactionIsolation == serializable)
Advantages:
- greatly simplifies code base
- High performance
- Portable
Disadvantages:
- If you want to have some synchronization and your DB doesn't support some
kind of select-for-update or doesn't support TransactionIsolation
serializable you're really shit out of luck. You could probably mix
optimistic locking with multiple instances, but you'd have the same problems
the optimistic locking gives you.
-------------------------------------------------------
Misc.
* you can mark entities read-only in jboss.xml. You really don't need to
lock at all for read-only entities.
-------------------------------------------------------
This table marks what I think are the best solutions for entity locking and
what scenarios they should be used.
Entity Type locking mechanism
----------------------------------------
read-only NO LOCKING
read-mostly optimistic locking
read/write Option A select-for-update, or classic jboss for datastores
not supporting
read/write Option B/C multiple instances synched by select-for-update or
db isolation level.
Now what DBs support select-for-update? I only know of Oracle can somebody
add to this table?
Select for update supported
---------------------------
Oracle YES
Sybase ?
Informix ?
DB2 ?
Postgres ?
mySQL ?
BerkelyDB ?
SQL Server ?
Others?
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
