|Sorry Georg,  I don't what planet I was on when I made the "option A with
|optimistic locking" comment.

Option A with optimistic locking would be interesting.

it is Option A with pessimistic db locking that doesn't really bring
anything new.

He was criticizing the "no copy of the cache" for a new transaction.  I
answered with the clone idea in teh cache.

The point is that these are CACHE IMPLEMENTATION dependent, I will make sure
the container flow supports these.

|Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate
|SQL*PLUS windows.  With autocommit off, it seems that if you try to update
|the same row in 2 different windows, one window waits until the other
|commits.  Wonder if this will happen with JDBC as well, I'll let you

pessimistic then...

|know....Anybody know the behaviour on this with other DBs?  Is this common
|locking behaviour?  If so, great!

we would have to implement the transaction isolation levels correctly in
jboss again I believe that lives at the jbossCMP level.  But if we are going
to support different vendors for the CMP engines we must take this part out
or at least offer a common API... hmmm must think about it.

|All in all, I think JBOSS should delegate synching and locking to the DB

sure but my point is that can be a cache decision, if you still want to
implement a pessimistic cache (like we have right now) with maybe a simple
"read-only" feature then you can.

In fact a READ ONLY cache could really improve throughput with copies of the
instances for the duration of the transaction.   It is then the cache
workspace that becomes XA aware... hmmm must think about it.

Add-on market??? here we come... we must enable these policies, that is what
I am fixing.

|wherever it can because the DB is usually more efficient at this.  Also,
|IMHO, this is really the best way to synch multiple instances of JBoss.

hmmmmm maybe... maybe not... some will argue that letting all the cache sync
on the database is not the best option... it is definitely the *simplest*
but certainly not the "best".. :)

marcf

|
|Regards,
|Bill
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to