On Mi, 2010-01-27 at 16:44 +0000, Lukas Zeller wrote:
> Hello Patrick,
>
> On Jan 26, 2010, at 17:38 , Patrick Ohly wrote:
> What about <datastoreinitscript> or maybe <initscript>? These are
> called before user data is accessed the first time, which would be
> early enough to stop the whole thing if needed, but late enough to be
> sure the sync mode is known. BTW: I realized that a useful document
> was missing in the docs so far - see my latest commit 9dc1e5c1a3 (Doc:
> useful table showing the call flow of scripts within a server session)
> on the luz branch.
Using the <datastoreinit> script works nicely on the client side, better
than the previous check in <alertscript>. Slow syncs forced by the
client side are now detected and prevented.
On the server side I need to do more testing. One thing that I already
noticed is that stopping to send messages is not suitable (if it ever
was in the client case), because the client will resend the last
message.
Another peculiarity: on the server, after calling ABORTDATASTORE(),
'ReadSyncSet' is done and items are read from the database as part of
'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
Shouldn't the engine skip these steps because the store has already
failed?
> What's currently missing would be some DS-level functions to query the
> sync mode, but that'll be simple to add (probably in customimplds.cpp,
> within TCustomDSfuncs). To differentiate unwanted from
> client-requested slow sync, we'd probably need two of them, like
> ALERTEDMODE and ACTUALMODE. Some functions along this line already
> exist, I'd have to check to make sure we don't duplicate stuff.
There is SLOWSYNC(), documented as "returns true if session is a slow
sync". I found that it also returns true on a client if the session is a
refresh-from-client. Is that intentional?
A refresh-from-client would be acceptable, so I am currently using
"if(SLOWSYNC() && ALERTCODE() != 203)".
Here's the log:
–[2010-01-29 19:19:07.699] 'DSStateChange' - Datastore changes state,
datastore=addressbook, oldstate=sync_mode_stable,
newstate=data_access_started [--][++] [->end] [->enclosing]
* [2010-01-29 19:19:07.699] TStdLogicDS::startDataAccessForServer
* [2010-01-29 19:19:07.699] - number of items in list before
StartDataRead = 0
* +–[2010-01-29 19:19:07.699] 'ScriptExecute' - Start executing
Script, name=datastoreinitscript [--][++] [->end] [->enclosing]
* [... script detects slow sync ...]
* ABORTDATASTORE(22000);
* [...]
* +–[2010-01-29 19:19:07.700] 'DSAbort' - Aborting
datastore sync, abortStatusCode=22000, localProblem=yes,
resumable=yes [--][++] [->end] [->enclosing]
* +–[2010-01-29 19:19:07.701] 'SessionAbort' -
Aborting Session, Status=22000,
ProblemSource=LOCAL [--][++] [->end] [->enclosing]
* [2010-01-29 19:19:07.701] WARNING:
Aborting Session with Reason Status
22000 (LOCAL problem) ***
* [2010-01-29
19:19:07.701] --------------- Ignoring
all commands in this message (after 0
sec. request processing, 0 sec. total)
with Status 514 (0=none) from here on
–[2010-01-29 19:19:07.701] End of
'SessionAbort' [->top] [->enclosing]
* [2010-01-29 19:19:07.701] addressbook:
testState=FALSE - expected
state>='sync_set_ready', found
state=='sync_mode_stable'
* +–[2010-01-29 19:19:07.701] 'SaveSuspendState' -
Saving state for suspend/resume,
datastore=addressbook [--][++] [->end] [->enclosing]
[...]
* [2010-01-29 19:19:07.702] *************** Warning:
Datastore flagged aborted (after 0 sec. request
processing, 0 sec. total) with LOCAL Status 22000
–[2010-01-29 19:19:07.702] End of
'DSAbort' [->top] [->enclosing]
* [2010-01-29 19:19:07.702] - ABORTDATASTORE() function result =
<NO FIELD>
* [...]
–[2010-01-29 19:19:07.703] End of 'ScriptExecute' [->top] [->enclosing]
* [2010-01-29 19:19:07.703] Type-specific postfetch filtering NOT
needed
* [2010-01-29 19:19:07.703] FilterSupport staticfilter:
dynamicfilter:
invisiblefilter:
* [2010-01-29 19:19:07.703] Datastore-level postfetch filtering NOT
needed
* [2010-01-29 19:19:07.703] MultiThread disabled
* [2010-01-29 19:19:07.703] deleteAllMaps: all existing map entries
(1) now marked deleted=1
* +–[2010-01-29 19:19:07.703] 'ReadSyncSet' - Reading Sync Set from
Database, datastore=addressbook [--][++] [->end] [->enclosing]
* [2010-01-29 19:19:07.703] ContextSupport ReadNextItem:allfields
* +–[2010-01-29 19:19:07.703] 'ScriptExecute' - Start executing
Script, name=initscript [--][++] [->end] [->enclosing]
* [...]
–[2010-01-29 19:19:07.703] End of
'ScriptExecute' [->top] [->enclosing]
* [2010-01-29 19:19:07.703] Now reading local sync set: report
changes since reference1 at 2010-01-29 18:18:58.000, and since
reference2 at 2010-01-29 18:19:07.631
* [2010-01-29 19:19:07.705] StartDataRead last='' resume='' res=0
* [2010-01-29 19:19:07.705] ReadNextItemAsKey aStatus=2
aID=(pas-id-4B63264F00000392,(null)) res=0
* [2010-01-29 19:19:07.705] read local item info in sync set:
localid='pas-id-4B63264F00000392'
* [2010-01-29 19:19:07.705] ReadNextItemAsKey aStatus=0
aID=((null),(null)) res=0
* [2010-01-29 19:19:07.706] EndDataRead res=0
–[2010-01-29 19:19:07.706] End of 'ReadSyncSet' [->top] [->enclosing]
* +–[2010-01-29 19:19:07.706] 'GetItems' - Read items from DB
implementation, datastore=addressbook [--][++] [->end] [->enclosing]
* [2010-01-29 19:19:07.706] Slow sync and not resuming -> all
items are first reported sop_wants_replace (will become add
later)
* [2010-01-29 19:19:07.706] ReadItemAsKey
aID=(pas-id-4B63264F00000392,) res=0
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
