Hi Sergei, >> Does it? I believe it deals with date/time formats, so I don't >> really see how this is related to what we do ...? We even do the >> time handling ourself in our DBI persister. >> > > > Not that simple. Before this patch "current time" was set only once: > near the beginning of the > Workflow's persister module. Then it was used several times. Hence > near > the end of the module > "current time" pointed to the past, which hampered the main sense of > persister operation. > And could let to the conflict very similar to our problem.
I don't think so, the persister writes the workflow history and adds the current timestamp to this data. This date is purely informational and is not used for anything in the system logic. I agree that it might be useful to cache a timestamp once and then write the same timestamp for the whole workflow instance. And to emphasize Alex's point: we do not use the Workflow::Persister::DBI at all, we have implemented our own. Jim's patch will not influence ours. Sorry for the brief answer, we are currently busy with our production deployment. > If OpenXPKI's persister module employs somewhat similar timing policy > (I failed to understand this), then this could lead to timing > problems too. If I am not totally mistaken then the persister should not cause any timing problems at all. > The patch of Jim Brandt sets "current time" anew each time when it > is used. Could you please point to a corresponding patch line? Cheers Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
