Helen,

I'm using Delphi with dbExpress and ClientDatasets in a 3-tier app.
My transaction configuration is:

CommitRetain=False
Interbase TransIsolation=ReadCommited

dbExpress should handle transactions automatically and I never worried about it.

What do you mean by "some abandoned ClientDataset"? My app is 3-tier,
so the ClientDataset is completely disconnected. My app server is
stateless. The db connection is not owned by any client.

Thanks.

--
Erick Sasse


2007/10/23, Helen Borrie <helebor@...>:

> At 01:20 PM 23/10/2007, you wrote:
> >I have a database with these statistics:
> >
> >Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 155293
> > Page size 1024
> > ODS version 11.0
> > Oldest transaction 126243
> > Oldest active 126244
> > Oldest snapshot 126243
> > Next transaction 155285
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 16
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 3
> > Creation date Oct 4, 2007 11:29:28
> > Attributes
> >
> > Variable header data:
> > Sweep interval: 20000
> > *END*
> >
> >
> >The difference from the oldest active to the next transaction is almost 30.000.
> >
> >The sweep interval is 20.000 so I thought the automatic sweeping would
> >clear this "lost" transactions when they reach 20.000. Am I wrong?
>
> Yes. :-)
>
> The transactions in the "gap" are not lost transactions. Some of them - perhaps even most of them - might have completed but they are still waiting for the garbage collector (or a sweep) to come and flag the old record versions as obsolete. Some are still running. However, if the OIT cannot be cleared, there will be no GC of record versions that remain "interesting" to the OIT.
>
> The oldest snapshot in your report is the same as the oldest ('oldest interesting') transaction. The oldest snapshot reports the transaction that was the oldest active the last time the GC or a sweep ran. Considering that the "gap" is past the threshold of 20,000 that is set for automatic sweep, you can assume that the auto sweep has run but has not been able to work on any transactions that are younger than the oldest [interesting] transaction.
>
> >I also tried to perform a manual sweeping but the numbers didn't change.
>
> Your manual sweep had the same result as the GC and the auto-sweep are having. Your OIT is *stuck*. Finding out which one would be impossible, since it is not longer active. However, some records that were touched by read-write transactions since the OIT started are still in use by more recent transactions.
>
> Do you have some large update or delete job that has not been hard-committed, or is waiting somewhere where it needs to be NO WAIT? Or (if you are using Delphi) perhaps some abandoned TClientDataset somewhere that is hanging off a read-write transaction? Are you perhaps using only "soft commits" in your applications? These are the more frequent culprits for stuck OIT...
>
> ./heLen
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>