Hi Helen,

thanks for your answer.

Helen Borrie wrote:

>
> Unbelievable but true. As far as I understand it, it has to do with the
> granularity (or lack thereof) of low-level timer calls on some POSIX
> platforms with a consequent design decision to generalise on the lowest
> common denominator to preserve cross-platformness. I consider it as a bug
> until it a) becomes correctable and b) gets corrected.

Exactly.

> >But perhaps someone has a solution for this.
>
> In Firebird 1.5, you can use the UDF GetExactTimestamp(), in the library
> fbudf.so. It doesn't take any argument but returns the exact timestamp
> down to ten-thousandths of a second. The declaration is in fbudf.sql.

Ahh, I've read that it is available only on win32 in the fbudf.sql. I
tried now and it works on both platforms.

> As for your timing and synchronicity problems...you appear to have some
> systemic flaws regarding transaction isolation and data visibility.

No, I don't think so. The STOCK_CONTENTS_LOG logging process must not
see changes in quantity that happened after it has started. Those
changes simply belong to next period.

The operation that logs the change in quantity (STOCK_ITEM_IN_OUT_LOG)
also changes the quantity registered on stock, so there can't be any
inconsistency. It all resides in one stored proc.

I know that using greater precision is not 100% efficient cure as there
still can be some change logged exactly at the same time as the
STOCK_CONTENTS_LOG logging process starts, but the probability is much
smaller. And we don't want to complicate it all just because of this
test.

And there was another question in my first message: Is it OK if FB
generates the same timestamps using cast('now' as timestamp) when it is
run under repeatable read transaction, while under read commited
transaction it would generate different timestamps ?
I mean, stored proc generates the first timestamp, then does something
else for a few seconds, and finally generates second timestamp.
Shouldn't timestamps generated this way be different no matter what the
transaction isolation is ?

Best regards,
Tom

P.S.
=================================

Tomas Michalik
ProCA, s. r. o.
V Luzich 818, Praha 4
Czech Republic

e-mail: michalik@...
tel: +420 234646446