db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Subject: Detectability of updates in DRDA
Date Wed, 08 Mar 2006 02:16:05 GMT

Hi,

Bryan Pendleton <bpendleton@amberpoint.com> writes:

> Frankly, my head is spinning trying to think about this. With all the
> various combinations of "own" updates versus "others" updates, transaction
> isolation levels, implicit and explicit rowsets, etc., this seems like
> a horribly complicated behavior to try to explain to a user.

Ah, yes, it is a messy area, isn't it? ;-) For insensitive result sets
I think we should be able to explain it pretty simply though; own
changes are visible and can be detected; other changes are not visible
and can not be detected. Given that we want to implement rowUpdated,
is using a warning interception as suggested kosher DRDA or not in
your view?

Given the current state of the SUR implementation, we can make this
information available, but I can't say much on how valuable it would
be for an app..  At least, it would free the app from keeping track of
which rows were changed by the user, say, when paging back and forth
in a result set, if highlighting changed rows were desired...

Thanks,
Dag

>
> I tried looking at the docs for a couple of other DB vendors, and they
> were full of lots of complex language about when the rowUpdated() method
> would and would not detect an actual update. Some vendors seemed to say
> that rowUpdated only detects updates made by others; some seemed to say
> that it only detects updates made by this result set; some just punted
> and said they don't support the method.
>
> For example:
> http://www.lc.leidenuniv.nl/awcourse/oracle/java.920/a96654/resltset.htm#1020514
> http://www.ipd.uka.de/~oosem/mobiledb/pb/docs/server_embedded/html/htmlfiles/dev_tutorial2.html
>
> Do we know anything about how actual applications use this method? Since
> I've never tried to use it myself, I don't think I can contribute much
> to the discussion about what might or might not be an acceptable implementation.
>
> thanks,
>
> bryan
>
>

-- 
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