| Subject | Re: [IBO] Threaded transaction not advancing |
|---|---|
| Author | Jason Wharton |
| Post date | 2001-10-23T18:16:35Z |
When I say automatic, I realize this is a big ambiguous. Let me clarify a
little more what I mean.
There are a few different things which will prevent IBO's ability to
automatically close a transaction handle to prevent the OAT getting stuck.
Let me just list them as things you still need to guard against in your
application. You either need to set the Force or at least Prompt actions in
the transaction timeout properties. Either that or just keep track yourself
how long the transaction has been opened and call Commit, Rollback or Close
yourself.
tiConcurrency isolation -
The reason this stops it is because you have asked the server to give you a
consistent view of the data. It is the transaction handle which locks you
in. If I automatically dispose of the handle then I have corrupted your view
of the database to give you a later committed view of things.
TIB_Cursor being left open -
Since this is a unidirectional, unbuffered dataset I am unable to close the
transaction handle because it is what the cursor needs for its context. If
you end a transaction all cursors on the server are lost. (commit retaining
means to retain cursors but the OAT remains stuck). It would make sense to
me that in the tiCommitted isolation that it shouldn't matter but InterBase
closes cursors even when in this isolation mode. (Look for a future time
when it won't matter in this mode as I think it should be possible.)
When there has been a DML or DDL executed -
Once there has been some sort of data or metadata manipulation it is the
transaction handle that keeps that change pending. As a result, I need to
preserve the handle so that the option to commit them or roll them back is
available. If a user makes some changes which are posted directly to the
server and then they get up and walk away from their machine there will be a
stuck transaction if you don't have another safeguard against it.
Also, when using explicit sessions you do not get the automatic idle thread
messages spurring action along to do this. It is also not a good idea to
have a TTimer operational in sub-threads. As a result, you need to take
measures to explicitly control your transactions. There is one transaction
that handles the SchemaCache requests that probably (come to think of it)
needs a manual call in order to not leave it open when the session isn't
getting idle CPU messages to feast upon. Since you are using IBO v3.x I
cannot remember just how it is called but there is a single method you call
to free up any allocated server resources. Try
MyConnection.FreeServerResources or directly access the transaction of the
MyCOnnection.SchemaCache.Transaction. You may want to check if it is
assigned as it is possible it could return nil.
I hope this helps illustrate better what IBO does and cannot do when trying
to keep the OAT good and healthy. In short, IBO will only do what it can in
a way that is transparent to your application and that will not corrupt the
context of your logical units of work. Where IBO is unable to move things
along I have provided the hooks and capabilities to allow you to determine
easily how to deal with the exceptional cases and distinguish what case it
is you are dealing with.
Helen, you may want to make this into a FAQ entry...
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
little more what I mean.
There are a few different things which will prevent IBO's ability to
automatically close a transaction handle to prevent the OAT getting stuck.
Let me just list them as things you still need to guard against in your
application. You either need to set the Force or at least Prompt actions in
the transaction timeout properties. Either that or just keep track yourself
how long the transaction has been opened and call Commit, Rollback or Close
yourself.
tiConcurrency isolation -
The reason this stops it is because you have asked the server to give you a
consistent view of the data. It is the transaction handle which locks you
in. If I automatically dispose of the handle then I have corrupted your view
of the database to give you a later committed view of things.
TIB_Cursor being left open -
Since this is a unidirectional, unbuffered dataset I am unable to close the
transaction handle because it is what the cursor needs for its context. If
you end a transaction all cursors on the server are lost. (commit retaining
means to retain cursors but the OAT remains stuck). It would make sense to
me that in the tiCommitted isolation that it shouldn't matter but InterBase
closes cursors even when in this isolation mode. (Look for a future time
when it won't matter in this mode as I think it should be possible.)
When there has been a DML or DDL executed -
Once there has been some sort of data or metadata manipulation it is the
transaction handle that keeps that change pending. As a result, I need to
preserve the handle so that the option to commit them or roll them back is
available. If a user makes some changes which are posted directly to the
server and then they get up and walk away from their machine there will be a
stuck transaction if you don't have another safeguard against it.
Also, when using explicit sessions you do not get the automatic idle thread
messages spurring action along to do this. It is also not a good idea to
have a TTimer operational in sub-threads. As a result, you need to take
measures to explicitly control your transactions. There is one transaction
that handles the SchemaCache requests that probably (come to think of it)
needs a manual call in order to not leave it open when the session isn't
getting idle CPU messages to feast upon. Since you are using IBO v3.x I
cannot remember just how it is called but there is a single method you call
to free up any allocated server resources. Try
MyConnection.FreeServerResources or directly access the transaction of the
MyCOnnection.SchemaCache.Transaction. You may want to check if it is
assigned as it is possible it could return nil.
I hope this helps illustrate better what IBO does and cannot do when trying
to keep the OAT good and healthy. In short, IBO will only do what it can in
a way that is transparent to your application and that will not corrupt the
context of your logical units of work. Where IBO is unable to move things
along I have provided the hooks and capabilities to allow you to determine
easily how to deal with the exceptional cases and distinguish what case it
is you are dealing with.
Helen, you may want to make this into a FAQ entry...
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, October 23, 2001 10:45 AM
Subject: Re: [IBO] Threaded transaction not advancing
> If you are using a TIB_Cursor are you making sure they get closed? IBO
> doesn't do anything automatic when you are using a unidirectional cursor.
> This is something you have to manually take care to use.
>
> Are you checking the Started property of the transaction to determine that
> it is ended? All transactions should be visible in the array of
> transactions.
>
> HTH,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Bill Morrison" <bmorrison@...>
> To: <ibobjects@yahoogroups.com>
> Sent: Tuesday, October 23, 2001 9:11 AM
> Subject: [IBO] Threaded transaction not advancing
>
>
> > I'm having a weird problem with 3.6.Dg running against IB 5.6.
> >
> > I have a datamodule that I am creating in a thread. This datamodule has
a
> > TIB_Connection component, to TIB_Transactions (tiCommitted), and some
> cursor
> > and dsql components.
> >
> > Now, if this datamodule is created outside of the thread (I was
> > inadvertantly creating it in the thread's constructor (main thread
> > context)), then everything runs fine, and the transactions advance
> normally.
> >
> > However, once I started creating the datamodule in the threads execute
> > method, the OAT and OIT will cease advancing on the server.
> >
> > All of the cursors and dsql are connected to one or the other
> transactions,
> > and the transactions are committing every ten seconds or so. Even
manually
> > setting a breakpoint and committing them in debug mode will not
increment
> > the OAT and OIT.
> >
> > Interestingly, if I look at the transactioncount property of the
> > TIB_Transaction, it returns 3. I thus assume that the third transaction
is
> > being created internally for some IBO internal housekeeping, and is for
> some
> > reason not incrementing it's OAT.
> >
> > Any assistance with this problem would be greatly appreciated!
> >
> >
> > Bill Morrison
> >
> >
> >
>
___________________________________________________________________________
> > IB Objects - direct, complete, custom connectivity to Firebird or
> InterBase
> > without the need for BDE, ODBC or any other layer.
> >
>
___________________________________________________________________________
> > http://www.ibobjects.com - your IBO community resource for Tech Info
> papers,
> > keyword-searchable FAQ, community code contributions and more !
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>