> Few databases support row-level locking (anecdotal, maybe this has
>changed), and those that do are often deployed with page-level locking for
>performance reasons.
Actually I believe Sybase, Oracle and DB2 all support row level locking. I
think IBM suggest using page level locking where possible because of the
overheads in maintaining row level locks
> With page-level locking, many transactions would be
>falsely rejected because they are "too close" too a record that is being
>modified.
Actually this should result in a deadlock at page level rather than false
rejection
>I find that a larger problem (that Jonathon also discussed) is the updating
>of dependent objects. These objects will frequently exist in tables other
>than the bean's "primary" table. Some applications will have the requirement
>that two users can make concurrent changes to a bean and it's dependent
>objects. For example, consider the "restaurant order" bean. It is feasible
>that one waiter could change the table associated with the order (a change
>to the bean - primary table), while a waitress could simultaneously change
>the order items (a dependent object - ancillary table).
Yes this is a nightmare in trying to keep track. Unless you have one
'owner' this can be impossible to manage, depending on the application
requirements..
>The only true place to implement concurrency is at the database or at a
>layer between all of the EJB containers and the database. You can only
>implement concurrency in *one* location. No matter how scalable we attempt
>to make our systems, there is always a place where all of our traffic
>funnels down to a single point. This place is the only place to implement a
>concurrency algorithm. For 95% of us that care about it, it is the database.
I agree with you but I keep thinking that the problem is that most
application servers are using the ejbLoad at all costs from the database
ala WebLogic and Websphere and that the problem is that few app servers
actually keep the object state in between transactions. IF they did and IF
the only way that data can be updated is via the application
server/container, then some of these concurrency issues MIGHT disappear. I
believe that Gemstone/J and perhaps Persistence PowerTier may do this. I
also believe that IBM San Francisco may also have done this.
This issue of concurrency has always been there in the pre-object days.
With the advent of data being 'retained' in objects, things just got
messier since state is on the disk (on the database) and also in memory...
I'm glad that everyone has raised this problem as it has been bugging me
for ages and it's good to see that everyone seems to have given it a lot of
thought (but without easy solution :-( )
cheers,
eddie
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
