Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Can Dataset Remain Cached After ApplyCachedUpdates ?
Tue, Jan 24 2012 8:16 PMPermanent Link

Gregory Sebastian

Hi all,
It seems that calling DBISamQuery.ApplyCachedUpdates deletes the cached copy and the dataset reverts to its normal un-cached state. I think this implementation is slightly different from the BDE's TQuery's where the dataset remains cached even when calling "ApplyUpdates" "CancelUpdates" as long as CachedUpdates := True .

1. Is there anyway I can get this behaviour in DBISamQuery. I.e when I ApplyCachedUpdates, the updates are applied to the remote database but the dataset remains cached locally until Refresh is called. I know I can just call BeginCachedUpdates again but there's a slight delay each time this is called. I was hoping there was a better way.

2.Also, where are the Cached copy stored? I don't see any temp files in the Client Side PrivateDir. Is it in memory ?

Thanks in advance
Greg
Wed, Jan 25 2012 10:15 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Gregory,

<< It seems that calling DBISamQuery.ApplyCachedUpdates deletes the cached
copy and the dataset reverts to its normal un-cached state. I think this
implementation is slightly different from the BDE's TQuery's where the
dataset remains cached even when calling "ApplyUpdates" "CancelUpdates" as
long as CachedUpdates := True . >>

DBISAM has to do it this way - it has to retrieve the current versions of
all of the records that were previously cached, anyways.  Remember, there
can be triggers and other pieces of code modifying the records on the other
end in ways that the cached versions of the records won't reflect.

<< 1. Is there anyway I can get this behaviour in DBISamQuery. I.e when I
ApplyCachedUpdates, the updates are applied to the remote database but the
dataset remains cached locally until Refresh is called. I know I can just
call BeginCachedUpdates again but there's a slight delay each time this is
called. I was hoping there was a better way. >>

Unfortunately, even if I could do so, I probably couldn't change this
without breaking a lot of existing code out there.  How much of a delay are
you seeing ? Also, how many records are you loading ?

<< 2.Also, where are the Cached copy stored? I don't see any temp files in
the Client Side PrivateDir. Is it in memory ? >>

It's stored in-memory, for performance/cleanup reasons.

--
Tim Young
Elevate Software
www.elevatesoft.com
Fri, Jan 27 2012 1:39 AMPermanent Link

Gregory Sebastian

Hi Tim,
<<How much of a delay are you seeing ? Also, how many records are you loading ?>>

Following are approx. only and done on a WAN with ADSL connection. Only 3 records were edited.

100 records result set : ApplyCachedUpdates = 3 secs, BeginCachedUpdates = 0.5sec
1000 records result set : ApplyCachedUpdates=3.2sec, BeginCachedUpdates= 1.5secs

Its pretty darn good already and I'm really pleased that caching support is built in. Both the Apply and the Begin does take significantly longer if the network is busy (like if my son is downloading a movie).  I could understand the Apply but I could not understand why the Begin would take any longer on a busy network.

Its quite rare that I Apply Updates without the need to Begin Updates again. It just feels a little counter productive that the Cache is always cleared only for us to call BeginCachedUpdates right after the Apply. If leaving the dataset cached after the Apply would give a performance boost and better end user experience, then maybe an optional parameter like :  ApplyCacheUpdates(RemainCached : Boolean) could be done without breaking anyone's code. I don't know what goes under the hood but if there no performance to be gained then its not a problem and I can just call Begin after the Apply.

Thanks
Greg
Tue, Feb 7 2012 11:48 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Gregory,

<< Following are approx. only and done on a WAN with ADSL connection. Only 3
records were edited.

100 records result set : ApplyCachedUpdates = 3 secs, BeginCachedUpdates =
0.5sec
1000 records result set : ApplyCachedUpdates=3.2sec, BeginCachedUpdates=
1.5secs >>

Do you have the RemoteReadSize property set for the
TDBISAMTable/TDBISAMQuery that you're using cached updates on ?  If not,
then the ApplyCachedUpdates call may take longer than necessary because it
resyncs the dataset after sending over the cached updates, and this may take
too long without setting the RemoteReadSize property.

You can see if this is the case by using the TDBISAMSession.OnRemoteTrace
event handler to log the requests/responses taking place when you perform
the cached updates:

http://www.elevatesoft.com/manual?action=viewevent&id=dbisam4&product=delphi&version=7&comp=TDBISAMSession&event=OnRemoteTrace

<< Its quite rare that I Apply Updates without the need to Begin Updates
again. It just feels a little counter productive that the Cache is always
cleared only for us to call BeginCachedUpdates right after the Apply. If
leaving the dataset cached after the Apply would give a performance boost
and better end user experience, then maybe an optional parameter like :
ApplyCacheUpdates(RemainCached : Boolean) could be done without breaking
anyone's code. I don't know what goes under the hood but if there no
performance to be gained then its not a problem and I can just call Begin
after the Apply. >>

Unfortunately, it wouldn't result in any performance benefit because DBISAM
would still need to re-load the records from the DBISAM Database Server
after the ApplyCachedUpdates call is complete.  There's just no way around
the fact that DBISAM has to send back any updated versions of the relevant
records after the record updates are applied.  Failure to do so would result
in stale records in the client-side cache, or worse, records that don't
reflect changes done on the back end.

--
Tim Young
Elevate Software
www.elevatesoft.com
Fri, Feb 10 2012 7:01 PMPermanent Link

Gregory Sebastian

Hi Tim
<<Do you have the RemoteReadSize property set for the
TDBISAMTable/TDBISAMQuery that you're using cached updates on ?>>

No I did not set it at all. Will try this out.

Thanks
Greg
Image