![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Tue, Jan 24 2012 8:16 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 AM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 PM | Permanent 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 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |