db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: conflict detection strategies
Date Thu, 16 Feb 2006 18:12:18 GMT

Hi,

Mike> It is true that the current access methods don't reuse row locations
Mike> until a table level lock is granted.  But your project would be the
Mike> first dependency on this outside of the access method implementations
Mike> themselves.  It is very clear the contract that the access methods
Mike> have with their clients while locks are held on the data they are
Mike> looking at, what you are proposing is a contract on unlocked data.

So, is the right approach to always lock all rows seen as part of an
updatable scrollable insensitive result set? Currently, this would
seem the only way to know whether an update/delete of a row can safely
be performed when navigating (back) to a previously seen row, since
non-locked rows are legal prey for compress, and there is no way(?) to
tell if a row on a page has changed its "identity" since the previous
read.

Some kind of notification from store before compress starts, as
proposed by Andreas, would allow invalidation of the result set to
take place, offering higher concurrency, at the price of a new
contract between store and the access layer. It would solve
rowlocation validity problem for both the "in-place" compress (which
apparently can happen before the transaction commits) and the off-line
compress (which is an issue when trying to realize holdability for
insensitive scrollable updatable result sets).

The standard doesn't really offer much help as to what should and
should not work here, since it requires updatable result sets to be
sensitive. For sensitive cursors, one would navigate back and forth
and there would be no (or less of a) need to remember and (in)validate
row locations.  But we are building insensitive.. ;-)

For the non-holdable case, I guess it boils down to a trade-off
between the desire to avoid locking all result set rows and the desire
to avoid new contracts between store and access...?

For the holdable case, I am not sure I see how we can implement that
without some kind of support from store..

Thanks,
Dag


Mike> 
Mike> Note that the current "in-place" compress will MOVE rows from one
Mike> row location to another if one does not have a row lock on the row.
Mike> This is done in the 2nd phase and only holds an intent lock, and
Mike> exclusive row locks on the rows being moved.
Mike> The off-line compress only does work under an X table lock.
Mike> So the row that you are updating actually will exist in the table,
Mike> but currently you will request the old location and will get back
Mike> a delete row indicator.  I think because of this option 1 does not
Mike> work.
Mike> 
Mike> The state of held cursors across commits is very murky in the standards.
Mike> We looked very carefully at forward only held cursors, and the standards
Mike> there are carefully worded to basically not promise anything about the 
Mike> rows that were viewed that preceded the commit (clearly since the 
Mike> standard says the only thing you can do after the commit is a next to 
Mike> get a new row or close - never can access rows looked at before the
Mike> commit).  What options are legal
Mike> implementations of updatable scrollable result sets for held cursors 
Mike> across commits?  Do the standards guarantee anything about data in the
Mike> cursor looked at before the commit?
Mike> 
Mike> 
Mike> 
Mike> Andreas Korneliussen wrote:
Mike> > Mike Matrigali wrote:
Mike> > ..
Mike> > 
Mike> >> If possible I would like to see a solution that does not require special
Mike> >> messages sent back and forth between modules about state.
Mike> >>
Mike> > 
Mike> > I am not entirely sure what restrictions you want to put on the design, 
Mike> > it is a bit unclear to me.
Mike> > 
Mike> > I have considered some other solutions:
Mike> > 
Mike> > 1. Change the locking behaviour, so that a table intent lock which is 
Mike> > set by an updatable cursor, is kept as long as the cursor is open - this 
Mike> > will ensure that the RowLocations are valid.
Mike> > 
Mike> > 2. After a commit, we could clear all data in the internal table in the 
Mike> > SUR. The problem with this approach is that the resultset would not 
Mike> > necessarily be repopulated with the same data - it would be sensitive 
Mike> > for changes across its own transactions commits, it would be highly 
Mike> > ineffecient.
Mike> > 
Mike> > 3. Let the cursors notify the OnlineCompress module that it should fail 
Mike> > any attempt to compress/defragment or purge the table.
Mike> > 
Mike> > More details on what I suggested yesterday:
Mike> > 
Mike> > The OnlineCompress class could provide an event mechanism, where 
Mike> > subscribers (OnlineCompressListener) register themselves to listen to 
Mike> > OnlineCompressEvents. The ScrollInsensitiveResultSet class could then 
Mike> > implement the OnlineCompressListener interface, and register itself once 
Mike> > it starts populating the table with RowLocations. The OnlineCompress 
Mike> > class then simply notifies all listeners once it is doing defragment / 
Mike> > compress.
Mike> > The listeners should unregister themselves (i.e 
Mike> > ScrollInsensitiveResultSet class could do it once it closes). The 
Mike> > OnlineCompress class could use a WeakHashMap to put the listeners into, 
Mike> > in case they are not well-behaved. I have not checked if derby already 
Mike> > has event manager type of modules, if it does, I would attempt to reuse 
Mike> > them.
Mike> > 
Mike> > Please also let me know if any of the other alternatives seems better.
Mike> > 
Mike> > 
Mike> > Andreas
Mike> > 
Mike> > 
Mike> >> Andreas Korneliussen wrote:
Mike> >>
Mike> >>
Mike> >>> Some context: In scrollable updatable resultsets, we populate an
Mike> >>> internal table with the following data:
Mike> >>>
Mike> >>> <Position> <RowLocation> <RowUpdated> <RowDeleted>
[<DataColumn>]+
Mike> >>>
Mike> >>> Example layeout:
Mike> >>>
Mike> >>>  1         <1,10>         false        false        1,"a",3
Mike> >>>  2         <1,11>         false        false        2,"b",2
Mike> >>>  3         <1,12>         false        false        3,"c",9
Mike> >>>
Mike> >>>
Mike> >>> When doing updateRow(), or deleteRow(), we use the RowLocation to
Mike> >>> navigate to the row being updated.
Mike> >>>
Mike> >>> Problem:
Mike> >>> For holdable cursors, we will release the table intent lock when doing
Mike> >>> commit on the transaction for the cursor.
Mike> >>>
Mike> >>> The table intent lock, prevents the system from doing a compress of
the
Mike> >>> table, causing all RowLocations to be invalid. In addition, it prevents
Mike> >>> reuse of RowLocation for deleted + purged rows.
Mike> >>>
Mike> >>> In order to support holdable scrollable updatable cursors, we consider
Mike> >>> having a service which allows the system to notify subscribers (i.e
Mike> >>> cursors) that it has executed i.e a compress.
Mike> >>>
Mike> >>> If the user then calls updateRow() or deleteRow(), we can then give
an
Mike> >>> exception like:
Mike> >>>
Mike> >>> "The row could not be updated, because its location has been updated
by
Mike> >>> the system"
Mike> >>>
Mike> >>> In addition, we consider having a reclaim of locks, so that immediatly
Mike> >>> after a commit, the new transaction with the holdable cursor, may
Mike> >>> reclaim the table intent lock.  This will reduce the time period which
Mike> >>> the system may compress the table, however not completely remove the
Mike> >>> possibility of a compress.
Mike> >>>
Mike> >>> Any comments on implementing such strategy ?
Mike> >>>
Mike> >>> An alternative to this strategy, could be to go the other way: cursors
Mike> >>> notify the system that it should not do compress.
Mike> >>>
Mike> >>> I would appreciate feedback on this topic, especially if you find any
Mike> >>> pitfalls with the proposed strategies, or have better alternatives.
Mike> >>>
Mike> >>> Andreas
Mike> >>>
Mike> > 
Mike> > 
Mike> > 
Mike> 
-- 
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

Mime
View raw message