Topic
4 replies Latest Post - ‏2009-05-12T11:02:57Z by SystemAdmin
SystemAdmin
SystemAdmin
6968 Posts
ACCEPTED ANSWER

Pinned topic SYNC_STATS vs DSY_STATS

‏2009-01-20T19:08:55Z |
Hi all,
We have configured everything in client and server to have SYNC_STATS, SYNC_SUBS_STATS and SYNC_TRACE syncronized. The tables are created in the client (Derby) when first synced.
But the problem is that the isync API is leaving the trace of syncing in other tables named DSY_STATS, DSY_SUBS_STATS, DSY_TRACE which are created in the client at isync startup even if the subscription set is not available for the user.

Anyone knows what's happening?

Thanks in advance
Updated on 2009-05-12T11:02:57Z at 2009-05-12T11:02:57Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    6968 Posts
    ACCEPTED ANSWER

    Re: SYNC_STATS vs DSY_STATS

    ‏2009-02-01T08:39:01Z  in response to SystemAdmin
    Yes, it's the disign.You can refer to http://publib.boulder.ibm.com/infocenter/db2e/v9r1/index.jsp.
    In the approach, the client information is uploaded to the server in three phases:
    1.Information collection: During synchronization, the sync engine writes the information to the Client Control Database1, which belongs to and is managed by the sync engine.The control tables are named DSY_STATS, DSY_SUBS_STATS, DSY_TRACE .
    2.Information propagation: Then, based on the directives given by the server, the sync engine will propagate the information into a user database (Upload DB). The upload DB tables are named SYNC_STATS, SYNC_SUBS_STATS and SYNC_TRACE. The phase can be executed asynchronously from the information collection phase. If it happens at the end of a synchronization session, the complete client information regarding that session can be obtained. It can also be executed right after the synchronization of each subscription to obtain the up-to-the-subscription information.
    3.Information upload: After the information is propagated to a user database, the user (application) can simply upload it just like regular user data.
    DSYCLIENTSTAT_SET associate with the subscription DSYCLIENTSTAT
    • SystemAdmin
      SystemAdmin
      6968 Posts
      ACCEPTED ANSWER

      Re: SYNC_STATS vs DSY_STATS

      ‏2009-05-08T09:13:02Z  in response to SystemAdmin
      Hi again,
      Thanks for the response.
      I've checked http://publib.boulder.ibm.com/infocenter/db2e/v9r1/index.jsp but haven't found anything about DSY_STATS,... tables or three stage sync.

      Anyway, we have on the device DB the tables DSY_STATS, DSY_SUBS_STATS, DSY_TRACE & MHDSY_STATS, MHDSY_SUBS_STATS, MHDSY_TRACE. These are created when first synced, even if DSYCLIENTSTAT_SET is not added to the group of users and isync.trace.* properties are off.

      When we add DSYCLIENTSTAT_SET to the group and turning on isync.trace.* properties on the server, the tables SYNC_STATS, SYNC_SUBS_STATS, SYNC_TRACE & MHSYNC_STATS, MHSYNC_SUBS_STATS, MHSYNC_TRACE are created on the device DB.

      But, sync info is collected into DSY_* & MHDSY_* tables but NEVER pushed into SYNC_* & MHSYNC_* so it's never uploaded to the server.

      Following your post, I suppose the second phase is not taking place on the device for some reason. So my questions are:
      ¿What directives must be given to the server and how?
      You said the phase can be executed on different times (before, after, asynchronously...) ¿What controls that behaviour?

      Thanks in advance
      • SystemAdmin
        SystemAdmin
        6968 Posts
        ACCEPTED ANSWER

        Re: SYNC_STATS vs DSY_STATS

        ‏2009-05-11T10:45:34Z  in response to SystemAdmin
        Uploading trace-isyn log file just in case it helps...
        thanks

        Attachments

        • SystemAdmin
          SystemAdmin
          6968 Posts
          ACCEPTED ANSWER

          Re: SYNC_STATS vs DSY_STATS

          ‏2009-05-12T11:02:57Z  in response to SystemAdmin
          Hi again,

          Diving into derby.log we've found that the engine was trying to push data from DSY_STATS to SYNC_STATS through these SQL sentences:

          select * from MHDSY_STATS;
          insert into SYNC_STATS values (?,?,?,?,?,?,?);

          The problem is that the DSYCLIENTSTAT subscription is defined to not subscribe the USER_ID field, so the insert sentence failed saying that the number of parameters is not correct.

          The final effect is that stats are not pushed into SYNC_* neither uploaded to the server.

          We've turned on the USER_ID field suscription on DSYCLIENTSTAT and things are working now.

          I suppose creation of DSYCLIENTSTAT & "config\template\server\dsyclientstat.xml" file should be fixed in the product package (we use Lotus Expeditor v6.1.2).

          Regards