I have not been following the scrollable updatable result set work, I had assumed that the work would be similar to the other resultset work in Derby with no special requirements from the store. Is there a proposed design for this project that I should go look at? I looked at the doc associated with DERBY-690, but there are a lot of suggested approaches - but not clear which choices have been made.
There is a lot of discussion about using the current support for update where current of. In the current system how does the system translate a user request for an update where current of, to the actual update of the row. Does it currently use RowLocation? If possible I would like to see a solution that does not require special messages sent back and forth between modules about state. 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 >
