>
>
> > > 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
>
> OK, thanks. Our DBAs have discouraged the use of row-level
> locking on our Sybase
> databases for exactly the same reason.
Actualy AFAIK every database performs better when using page level locking.
Its simple really. If each page contains N rows then you have N * pages
locks to track. Which means N*pages entries in a hashtable you are looking
up etc. Row level locking is suggested only for those applications where
your design assumed row level locking.
But the last thing we need is a row vs. page level locking argument,
especially from Sybase <wink>
Dave Wolf
Internet Applications Division
Sybase
>
> > > 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
>
> True, a deadlock exception is raised. To the developer, this appears as a
> SQLException. They must retry the update. This get's into another
> pet-peeve area
> of mine. We need a set of standard JDBC exceptions defined and
> supported by JDBC
> drivers so we can tell the difference between UniqueIndexException,
> DuplicateRecordException, DeadlockException, etc.
>
> > 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.
>
> The concept of caching state *is* supported by every major EJB vendor. The
> problem is that this approach fails miserably in a clustered
> environment. I
> should add that this approach (even in a single ejb container
> scenario) is not
> very practical in *real-world* applications.
>
> jim
>
> ==================================================================
> =========
> 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".
>
>
===========================================================================
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".
