Subject | Re: [IBO] Transaction Timeout w/Multithreaded app |
---|---|
Author | Jason Wharton |
Post date | 2003-02-28T05:59:16Z |
Thanks for pointing this information out. Using transactions in
multi-threading does seem to be a trouble spot waiting to catch an
unsuspecting developer. Does anyone have any suggestions on how we can help
insure people don't get stuck? One thing I did do that I may want to triple
check is have the metadata queries check to see if there is an active timer
on the associated session and if there isn't they will immediately close the
transaction used for it's select. This adds in a little overhead to use a
single transaction for each metadata query but at least there isn't the
possibility it will get left open. Would someone out there be kind enough to
verify this for me independently?
In short, with multi-threading you need to manage your own transactions
explicitly and IBO should manage its own internal transactions without you
the developer having to do anything special for it. That's the goal.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
-- We may not have it all together --
-- But together we have it all --
multi-threading does seem to be a trouble spot waiting to catch an
unsuspecting developer. Does anyone have any suggestions on how we can help
insure people don't get stuck? One thing I did do that I may want to triple
check is have the metadata queries check to see if there is an active timer
on the associated session and if there isn't they will immediately close the
transaction used for it's select. This adds in a little overhead to use a
single transaction for each metadata query but at least there isn't the
possibility it will get left open. Would someone out there be kind enough to
verify this for me independently?
In short, with multi-threading you need to manage your own transactions
explicitly and IBO should manage its own internal transactions without you
the developer having to do anything special for it. That's the goal.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
-- We may not have it all together --
-- But together we have it all --
----- Original Message -----
From: <riaan@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, February 20, 2003 12:29 PM
Subject: Re: [IBO] Transaction Timeout w/Multithreaded app
Bjørge,
My experience with IBO / transactions / multi-threading (IBO 3.6Dg -
currently looking at IBO4) which I post here as much as to get
comments as to be of possible assistance...
1. All IBO components in a thread (for a multi-threaded app.) should
be linked to a TIB_Session component that is unique to each thread.
The abbreviated code sequence (each thread)
IB_Session = new TIB_Session(NULL);
IB_Connection = new TIB_Connection(IB_Session);
IB_Query = new TIB_Query(IB_Session);
Maybe the frozen GUI had something to do with sharing the default
sesssion among the threads in the application?
2. The automatic commit of transactions has to do with a timer event
being managed by the session (if this is not correct, please
comment). For explicitly created sessions, this timer event is
disabled; quoting from the help file :
(TIB_Session.TimerInterval) "For explicit sessions the default is 0
which disables the timer. This is because some models of threading
may not work with the timer. So, I have it disabled in order to avoid
problems."
3. The problem I have is that the transaction started by IBO when
reading stuff from the system tables when the first query is opened,
does not get closed as is the usual case. The result was that
the 'oldest transaction' got stuck, leading to problems with garbage
collection. The workaround (which I don't like) is to use the
connection's 'Transaction[]' property to commit all transactions at
a point in the software where I know there shouldn't be any open
transactions.
4. I believe that IB7 is 'thread-safe' - will that change the
approach in using IBO with multi-threaded applications?
Best regards
Riaan Bosch