Hi,
I stumbled upon an interesting locking behavior in Derby 10.2.2.0 yesterday
and thought I'd post to the list to get a better understanding of what's
happening under the covers. Assume a table with two indexes:
create table MY_TABLE (
ID bigint,
FOO varchar(255),
BAR varchar(255),
Hi,
I might be showing my ignorance here but will probably learn in the process.
I looked at
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts15366.html and
found under Table 3 that for TRANSACTION_READ_COMMITTED, it is possible to
see phantom reads. I think what Alex is encountering is
Mamta Satoor wrote (2007-01-18 13:54:28):
Hi,
I might be showing my ignorance here but will probably learn in the process.
I looked at
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts15366.html and
found under Table 3 that for TRANSACTION_READ_COMMITTED, it is possible to
see
Alex Boisvert wrote:
Hi,
I stumbled upon an interesting locking behavior in Derby 10.2.2.0
http://10.2.2.0 yesterday and thought I'd post to the list to get a
better understanding of what's happening under the covers. Assume a
table with two indexes:
create table MY_TABLE (
ID
Mamta Satoor wrote:
Hi,
I might be showing my ignorance here but will probably learn in the
process. I looked at
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts15366.html
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts15366.html and
found under Table 3 that for
Correct - That is actually how Sybase ASE behaves (non-MVCC model).
On 1/18/07, Øystein Grøvlen [EMAIL PROTECTED] wrote:
I think most database systems that do not have multiversion concurrency
will behave as describe. When a scan encounters a exclusively locked
row, it will generally not
On 1/18/07, Øystein Grøvlen [EMAIL PROTECTED] wrote:
I think most database systems that do not have multiversion concurrency
will behave as describe. When a scan encounters a exclusively locked
row, it will generally not know whether the uncommitted operation is an
insert or an update.
