| Subject | Re: [IBO] more about transactions |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-03-10T10:13:28Z |
At 09:25 AM 10/03/2003 +0000, you wrote:
naughty users who go away and have coffee while a transaction is open. It
really doesn't have a use for "one-shot" DML tasks.
of task.
if not transaction1.started then
starttransaction;
If you do start the transaction in code, then you must end it in code as
well, and trap exceptions.
For a positioned update (one that updates a large batch of rows with no
WHERE clause, or a very broad spectrum, commit it following execution.
For a searched update, which targets one row or just a few, via a stricter
WHERE clause with replaceable parameter values, it will commonly be more
efficient to defer committing until the whole task is complete.
But, if you have rows in other transactions that depend on the updated
rows, then commit them as they execute (in this case, if it is a similar
task to be repeated over and over, you might as well use AutoCommit).
I'm really loath to say "always do this" or "never do that" regarding
transactions. As a designer, you need to think about the **actual task**
that is being wrapped inside the transaction context. If you can put a
"rope" around a task, even if has several steps, then it is most likely
that all of those tasks should be enclosed in a single transaction.
In a few scenarios, you might need to serialise tasks: complete one unit
of work before allowing another to proceed. In this kind of case, you want
to commit and permit entirely according to YOUR rules. Here, you might let
a piece of work be posted and hard-committed, before you proceed to set up
the next transaction context (read "set of conditions to perform a
task"). In this case you won't want to AutoCommit, because it doesn't end
the transaction context. But you won't want to be waiting for a timer, either!
Helen
>Helen,No. The timer function is there to protect transaction cleanup from
>
>I'm sorry to confuse you with bad code.
>This is just an example. I'm aware of the fact that I do not give my
>parameter a value. It's a first time query only performing one time.
>After that it's ok if it's committed immediately.
>
>My main question is: is it good practise to let IBO commit the
>transaction using it's timer function?
naughty users who go away and have coffee while a transaction is open. It
really doesn't have a use for "one-shot" DML tasks.
>Is it better to commit itIf by "manually" you mean using StartTransaction, then yes, for this type
>manually,
of task.
>and if so must I use starttransaction, or just let fb startIMO it is better practice to have your *code* control the transaction. So...
>the transaction automatically ?
if not transaction1.started then
starttransaction;
If you do start the transaction in code, then you must end it in code as
well, and trap exceptions.
For a positioned update (one that updates a large batch of rows with no
WHERE clause, or a very broad spectrum, commit it following execution.
For a searched update, which targets one row or just a few, via a stricter
WHERE clause with replaceable parameter values, it will commonly be more
efficient to defer committing until the whole task is complete.
But, if you have rows in other transactions that depend on the updated
rows, then commit them as they execute (in this case, if it is a similar
task to be repeated over and over, you might as well use AutoCommit).
I'm really loath to say "always do this" or "never do that" regarding
transactions. As a designer, you need to think about the **actual task**
that is being wrapped inside the transaction context. If you can put a
"rope" around a task, even if has several steps, then it is most likely
that all of those tasks should be enclosed in a single transaction.
In a few scenarios, you might need to serialise tasks: complete one unit
of work before allowing another to proceed. In this kind of case, you want
to commit and permit entirely according to YOUR rules. Here, you might let
a piece of work be posted and hard-committed, before you proceed to set up
the next transaction context (read "set of conditions to perform a
task"). In this case you won't want to AutoCommit, because it doesn't end
the transaction context. But you won't want to be waiting for a timer, either!
Helen