Board index » delphi » IBX Tansaction and TIBDataSet.

IBX Tansaction and TIBDataSet.

I have read in this newsgroup that is better to limit the time of a
transaction because this reduce the resources
allocated by the server.

I have some TIBDataset that is defined in datamodules with only one
TIbTransaction component for all TIBDataset. All the TibDataSet components
have activate the cache updates (in delphi 5.1 pro with Ibx 4.2).
In the afterpost method i use the ApplyUpdates method of the TIbDataBase
component and if something goes wrong i call the rollbackretaining method of
the transaction component.

So i don't explicit call the methods of the TIbTransaction component to
activate or deactivate the tansaction.

Is this correct ?
Is rigth to use only one Transaction for all the datasets or is better to
have a single TibTransaction for every tIbDataSet ?
The TeamB have some gold rules for use and manage correctly the transactions
?

Thank you for all the answers.

Massimo.

 

Re:IBX Tansaction and TIBDataSet.


Quote
Massimo Montrasio wrote:

> I have read in this newsgroup that is better to limit the time of a
> transaction because this reduce the resources
> allocated by the server.

> I have some TIBDataset that is defined in datamodules with only one
> TIbTransaction component for all TIBDataset. All the TibDataSet components
> have activate the cache updates (in delphi 5.1 pro with Ibx 4.2).

> In the afterpost method i use the ApplyUpdates method of the TIbDataBase
> component and if something goes wrong i call the rollbackretaining method of
> the transaction component.

Then why are you in CachedUpdates?  I see no behavior change between normal
working mode and Cachedupdates is you apply the updates immediately every time
you post a change.  Just work straight with the transaction and eliminate the
unnecessary caching mode.

Quote
> So i don't explicit call the methods of the TIbTransaction component to
> activate or deactivate the tansaction.

> Is this correct ?

RollbackRetaining or CommitRetaining just leave the transaction open.  You
should still be explicitly starting the transaction.  Do not let it be auto
started by a IBDataset.

Quote
> Is rigth to use only one Transaction for all the datasets or is better to
> have a single TibTransaction for every tIbDataSet ?

Totally depends on your application and needs.  Some things needs to have
multiple datasets all work within the same transaction context.  Sometimes they
can be individual.  I tend to have one transaction per form in MDI type apps so
everything in a form (actually in the DM associated with the form) is working in
the same view of the database.

Quote
> The TeamB have some gold rules for use and manage correctly the transactions
> ?

There are no hard and fast rules.  I've never seen a situation where each
dataset logically needed its own transaction.  Group as many datasets as
logically needed per transaction.  

Also there is no hard and fast rule as to what determines a short transaction
time.  It depends on your application.  If you are doing a lot of reads with
little data changing you can keep transactions open for a much longer period of
time.  

The thing to remember is the longer you keep a transaction going the more record
versions that IB will have to keep around.  The real place this affects things
is when garbage collection fires.  Long outstanding OIT (oldest Interesting
Transactions) will cause more garbage to be in the database because the garbage
collector thinks you might still need it.

Quote
> Thank you for all the answers.

> Massimo.

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
{*word*269}s giggle with their bodies glowing bright.  Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
  (new classic Genesis) Carpet Crawlers 1999

Re:IBX Tansaction and TIBDataSet.


First of all thank you very much for your efforts on develop the IBX
Components and for your explanations about my question.

"Jeff Overcash (TeamB)" wrote :

Quote

> Then why are you in CachedUpdates?  I see no behavior change between
normal
> working mode and Cachedupdates is you apply the updates immediately every
time
> you post a change.  Just work straight with the transaction and eliminate
the
> unnecessary caching mode.

I thougth that CacheUpdates was the best method to implement an undo
function when the user cancel the changes to the record in edit or insert
mode.
But with transactions in a MDI type apps i can activate an edit method in
two different forms simultaneously on two TibDataset that have the same
transaction ?
In other words how i can read and editing data with the opportunity to undo
the change without having a transaction active between the edit  or insert
method and the afterpost method of the dataset ?
You have some suggestion about this situation ?

Thanks.

Massimo

Quote
> > So i don't explicit call the methods of the TIbTransaction component to
> > activate or deactivate the tansaction.

> > Is this correct ?

> RollbackRetaining or CommitRetaining just leave the transaction open.  You
> should still be explicitly starting the transaction.  Do not let it be
auto
> started by a IBDataset.

> > Is rigth to use only one Transaction for all the datasets or is better
to
> > have a single TibTransaction for every tIbDataSet ?

> Totally depends on your application and needs.  Some things needs to have
> multiple datasets all work within the same transaction context.  Sometimes
they
> can be individual.  I tend to have one transaction per form in MDI type
apps so
> everything in a form (actually in the DM associated with the form) is
working in
> the same view of the database.

> > The TeamB have some gold rules for use and manage correctly the
transactions
> > ?

> There are no hard and fast rules.  I've never seen a situation where each
> dataset logically needed its own transaction.  Group as many datasets as
> logically needed per transaction.

> Also there is no hard and fast rule as to what determines a short
transaction
> time.  It depends on your application.  If you are doing a lot of reads
with
> little data changing you can keep transactions open for a much longer
period of
> time.

> The thing to remember is the longer you keep a transaction going the more
record
> versions that IB will have to keep around.  The real place this affects
things
> is when garbage collection fires.  Long outstanding OIT (oldest
Interesting
> Transactions) will cause more garbage to be in the database because the
garbage
> collector thinks you might still need it.

> > Thank you for all the answers.

> > Massimo.

> --
> Jeff Overcash (TeamB)
>       (Please do not email me directly unless  asked. Thank You)
> Mild mannered supermen are held in kryptonite, and the wise and foolish
> {*word*269}s giggle with their bodies glowing bright.  Through the door a
harvest
> feast is lit by candlelight; it's the bottom of the staircase that spirals
out
> of sight.
>   (new classic Genesis) Carpet Crawlers 1999

Re:IBX Tansaction and TIBDataSet.


Quote
> From: Jeff Overcash (TeamB)

Hi,

Quote
> Also there is no hard and fast rule as to what determines a short
> transaction
> time.  It depends on your application.  If you are doing a lot of
> reads with
> little data changing you can keep transactions open for a much
> longer period of time.

People often use the definition of 'Short' wrongly (me included <g>).  A
transaction can be as long (time) as required as long as it is doing
something.  If you transaction is idle, you probably want to do something
about it.  Whilst doing a 2 hour batch job in one transaction is OK, filling
a grid with 1000 records and letting the user 'browse' for a long time with
the transaction open is not so good.

As a general rule I use "StartTrans->DoSomething->StopTrans", if there is
ever a gap (time) between DoSomething and StopTrans I take another look at
my app.

A lot of people use a "Transaction per Modal Form", as it discourages users
from leaving result sets open, others cache the data on the client app so
the user can browse that data for hours outside of the transaction context,
but it all depends on the application.

Cheers

Phil

Re:IBX Tansaction and TIBDataSet.


Quote
Massimo Montrasio wrote:

> I thougth that CacheUpdates was the best method to implement an undo
> function when the user cancel the changes to the record in edit or insert
> mode.

Just call Cancel to cancel the current Edit or Insert.  CachedUpdates are only
needed when you want to cancel past the most recent edit or insert.

Quote
> But with transactions in a MDI type apps i can activate an edit method in
> two different forms simultaneously on two TibDataset that have the same
> transaction ?

Yes.  you would still have cancel ability on the current edit or insert.  What
you would have to be careful of is rollback on one form affects the other.  If
that is not what you want then this would be a good place to have a transaction
on each form.

Quote
> In other words how i can read and editing data with the opportunity to undo
> the change without having a transaction active between the edit  or insert
> method and the afterpost method of the dataset ?

With IBX while you have the Dataset open you must have the transaction open.
There really isn't anything wrong with this.  InterBase is different than other
RDBMS because of its multiple generational nature here.  A lot fewer locks are
ever placed on the DB than in a traditional.  Repeatable reads is done without
any record locking at all.

Quote
> You have some suggestion about this situation ?

> Thanks.

> Massimo

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Mild mannered supermen are held in kryptonite, and the wise and foolish
{*word*269}s giggle with their bodies glowing bright.  Through the door a harvest
feast is lit by candlelight; it's the bottom of the staircase that spirals out
of sight.
  (new classic Genesis) Carpet Crawlers 1999

Re:IBX Tansaction and TIBDataSet.


Hi Phil,

Quote
>a grid with 1000 records and letting the user 'browse' for a long time with
>the transaction open is not so good.

What would you suggest as alternative? Should I fill a Stringgrid or a
listbox with my query, only that I can close the Transaction
immediatly?
In my application, I have about 1000 students with their exams. In the
main window I work with a list of these students, so I need a dataset
open on the table with the students.

cu Christian

Other Threads