> A while ago I mentioned some customers have poor performance, especially when > 20 connections. I'm aware of the fact that there is a design problem, I just can't figure out what exactly.
> I checked with gstat and saw the following (probably disturbing numbers) :
>
> Oldest transaction : 91891
> Oldest active : 2956068
> Oldest snapshot : 2956068
> Next transaction : 2956086
>
> I guess the gap between Oldest en Next transaction is way too big ? Am I right ? After doing a sweep, the Oldest and Next become equal.
> I've read some articles on IBPhoenix, but I don't quite understand it. And I don't know what is causing that giant gap between Oldest and Next. All queries are set to AutoCommit, so when a record is inserted/updated, the transaction is committed. Or am I missing something ?

The oldest (interesting) transaction (OIT) is the oldest transaction in
a different state than committed. As OAT was able to move forward and a
sweep did cure the problem, I guess there was either a largish
transaction, which was rolled back (and the engine wasn't able to
transform that into a commit) or you have a stuck transaction in context
of a distributed transaction aka 2PC. Although, sweep isn't able to
recover the latter.



--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/