Mike Matrigali wrote:
..
If possible I would like to see a solution that does not require special
messages sent back and forth between modules about state.
I am not entirely sure what restrictions you want to put on the design,
it is a bit unclear to me.
I have considered some other solutions:
1. Change the locking behaviour, so that a table intent lock which is
set by an updatable cursor, is kept as long as the cursor is open - this
will ensure that the RowLocations are valid.
2. After a commit, we could clear all data in the internal table in the
SUR. The problem with this approach is that the resultset would not
necessarily be repopulated with the same data - it would be sensitive
for changes across its own transactions commits, it would be highly
ineffecient.
3. Let the cursors notify the OnlineCompress module that it should fail
any attempt to compress/defragment or purge the table.
More details on what I suggested yesterday:
The OnlineCompress class could provide an event mechanism, where
subscribers (OnlineCompressListener) register themselves to listen to
OnlineCompressEvents. The ScrollInsensitiveResultSet class could then
implement the OnlineCompressListener interface, and register itself once
it starts populating the table with RowLocations. The OnlineCompress
class then simply notifies all listeners once it is doing defragment /
compress.
The listeners should unregister themselves (i.e
ScrollInsensitiveResultSet class could do it once it closes). The
OnlineCompress class could use a WeakHashMap to put the listeners into,
in case they are not well-behaved. I have not checked if derby already
has event manager type of modules, if it does, I would attempt to reuse
them.
Please also let me know if any of the other alternatives seems better.
Andreas
Andreas Korneliussen wrote:
Some context: In scrollable updatable resultsets, we populate an
internal table with the following data:
<Position> <RowLocation> <RowUpdated> <RowDeleted> [<DataColumn>]+
Example layeout:
1 <1,10> false false 1,"a",3
2 <1,11> false false 2,"b",2
3 <1,12> false false 3,"c",9
When doing updateRow(), or deleteRow(), we use the RowLocation to
navigate to the row being updated.
Problem:
For holdable cursors, we will release the table intent lock when doing
commit on the transaction for the cursor.
The table intent lock, prevents the system from doing a compress of the
table, causing all RowLocations to be invalid. In addition, it prevents
reuse of RowLocation for deleted + purged rows.
In order to support holdable scrollable updatable cursors, we consider
having a service which allows the system to notify subscribers (i.e
cursors) that it has executed i.e a compress.
If the user then calls updateRow() or deleteRow(), we can then give an
exception like:
"The row could not be updated, because its location has been updated by
the system"
In addition, we consider having a reclaim of locks, so that immediatly
after a commit, the new transaction with the holdable cursor, may
reclaim the table intent lock. This will reduce the time period which
the system may compress the table, however not completely remove the
possibility of a compress.
Any comments on implementing such strategy ?
An alternative to this strategy, could be to go the other way: cursors
notify the system that it should not do compress.
I would appreciate feedback on this topic, especially if you find any
pitfalls with the proposed strategies, or have better alternatives.
Andreas
