Help with "458: Long transaction aborted."
Len Charest
Is it possible to avoid the dreaded "458: Long transaction aborted."
error without taking either of the actions recomended by the finderr
docs, namely "replan [the app] so that it modifies fewer rows per
transaction" or increase number/size of logical logs?
Can LOCK TABLE inside of a transaction be of help?
Thanks,
--
Len Charest l...@cogent.net
Senior Software Engineer 888-4-COGENT
Cogent Software, Inc. http://www.cogent.net/
Jacek Baran
You have some possible ways:
1. LOCK every tables in transaction. I'm not sure that help you, because
this
way is good when you get error "No more locks".
2. LOCK tables and declare cursor FOR UPDATE and inside loop delete or
update rows with WHERE CURRENT OF CURSOR ... option. It's not so fast.
3. If you delete more rows than stay in table.
In this case I create new table and in one instruction insert all need
rows to this table and than drop old table and rename new to name of old
table
4. You can divide your delete or update instruction to some parts which
works on "n" rows (n - for example 10.000 rows it's depend how big are
logs)
5. Try to do your operation when you ONE in database.
Jacek Baran
Jacob Salomon
>
> Hi-
>
> Is it possible to avoid the dreaded "458: Long transaction aborted."
> error without taking either of the actions recomended by the finderr
> docs, namely "replan [the app] so that it modifies fewer rows per
> transaction" or increase number/size of logical logs?
I know of no other ways. I prefer to enlarge the log spaces because
that does not force you to contort your application. And you obviously
need the log space; this is no time to get chincy on disk space!
That said, I would also mention that I have seen many flawed apps that
issue a BEGIN WORK (or, for mode ANSI databases, just get started) but
never issue a COMMIT until the end of the program, despite the logically
separate operations that should be in their own separate transactions.
If this is the your case you really should "replan" (who's making up
words here? ;-) your apps and visibly separate the transactions.
> Can LOCK TABLE inside of a transaction be of help?
Not at all. It might keep you from running out of locks, another
potential problem in a large transaction. But it has nothing to do with
the number of log records written while trying to do all that work.
--
-- Jake (Retrospectively realizes there is no future in hindsight)
+------------------------------------------------------------+
| The expedient performance of a task with excessive concern |
| regarding its duration-to-completion engenders a virtual |
| certainty of diminished benefit therefrom. |
| -- Benjamin Franklin (but he said it in 3 words) |
+------------------------------------------------------------+
RG
but this could cause other problems, and does require a bounce of the
engine. Your best bet is to add some logical logs. This would be both the
easiest and safest way, without modifying code.
--
Regards,
Robert
Len Charest <l...@cogent.net> wrote in article <361434...@cogent.net>...
> Hi-
>
> Is it possible to avoid the dreaded "458: Long transaction aborted."
> error without taking either of the actions recomended by the finderr
> docs, namely "replan [the app] so that it modifies fewer rows per
> transaction" or increase number/size of logical logs?
>
> Can LOCK TABLE inside of a transaction be of help?
>
DirkM
your transaction will continue a while longer before rolling back (and fill
up more logical log space) and when it does actually roll back there might
not be enough log space to do the roll back and the system will get stuck.
The safest is to increase your logs and try again.
Regards
Dirk
RG <rgri...@farmerstel.com> wrote in article
<01bdeff2$5afe9600$e44689d0@rgriffin>...
David Williams
<di...@vodac.co.za> writes
>Setting LTXHWM to a higher value is dangerous to do. It just means that
>your transaction will continue a while longer before rolling back (and fill
>up more logical log space) and when it does actually roll back there might
>not be enough log space to do the roll back and the system will get stuck.
>The safest is to increase your logs and try again.
>
>Regards
>Dirk
>
--
David Williams
Maintainer of the Informix FAQ
Primary site (Beta Version) http://www.smooth1.demon.co.uk
Official site http://www.iiug.org/techinfo/faq/faq_top.html
I see you standin', Standin' on your own, It's such a lonely place for you, For
you to be If you need a shoulder, Or if you need a friend, I'll be here
standing, Until the bitter end...
So don't chastise me Or think I, I mean you harm...
All I ever wanted Was for you To know that I care