db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: RowLocation lifetime
Date Thu, 10 Nov 2005 17:02:04 GMT
Hi,

  We are planning on using RowLocation to position the cursor when doing 
scrollable updatable cursors (i.e when navigating backwards in the 
resultset) - see 
http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/10028 for 
more details.

The fact that the RowLocation could become invalid, do worry me a bit.

I did a test on a simple select statement, using transaction level 
read-uncommitted.

T1: select * from testtable

Then (before doing commit) I called on another connection:

T2: call SYSCS_UTIL.SYSCS_COMPRESS_TABLE("APP", "TESTTABLE", 0)
T2: Got exception:The exception 'SQL Exception: A lock could not be 
obtained within the time requested' was thrown while evaluating an 
expression.

So even in read-uncommitted mode, a lock intent level lock on the table 
is set (good), and it seems to be held until I close the resultset or 
commit the transaction T1.

The problem I then see is for cursors that are held over commit 
(ResultSet.HOLD_CURSORS_OVER_COMMIT). Maybe we should not support it for 
scrollable updatable resultsets.

Anyway , we would really appreciate to get some comments on the 
specification Dag sent out two days ago, to ensure that we are on the 
right track.

Thanks

-- Andreas

Mike Matrigali wrote:
> Assuming row is not deleted, the question can only be answered
> knowing the isolation level.  Basically the RowLocation can only
> be counted on while a lock intent level lock is held on the table.
> Intent table locks may be released as soon as a statement is
> completed, or may be held to end of transaction depending on
> the type of statement and type of isolation level.
> 
> The thing that may move an existing row in a heap are the compress
> table system procedures.
> 
> If a row is deleted then there are other factors.
> 
> Rick Hillegas wrote:
> 
>> Hello Store experts,
>>
>> How long is a RowLocation in a Heap good for? Provided that the row is 
>> not deleted, can you count on its RowLocation reliably identifying the 
>> row for the duration of a Statement, a Transaction, a Connection? 
>> Forever?
>>
>> Thanks,
>> -Rick
>>
>>
> 


Mime
View raw message