Looks good to me
Firebird/interbase supports select for update
david jencks
On 2001.07.24 11:28:04 -0400 Bill Burke wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
