RE: Long Transactions and table locking

Every sql is an implicit transaction. So deleting 5 kajilion rows with one statement can cause a long transaction to occur as well. If the box isnt a real busy one I imagine you can see what your program is doing with onstat -g ses to locate what statement is causing your grief. People have mentioned that on boxes with high user activity, onstat -g ses can lock up the box. (I do not have any boxes that are active enough to cause this, so do not speak from experience) Will >===== Original Message From "Paul Harman" <paul@kasterborus.demon.co.uk> ===== >Rudy Fernandes <rferdy@americasm01.nt.com> wrote in message >news:38C561B0.98C0910B@americasm01.nt.com... >> The "Long Transaction" error can affect transactions that take very little >log >> space as well (although this rarely happens). Informix marks a transaction >as >> "Long" when its BEGIN WORK entry is in a log more that LTXHWM % away from >the >> current log. This does not mean the specific transaction has used all that >log >> space. > >Thanks for the reply, Rudy. > >However, I'm not explicitly using transactions anywhere within the >application - it's all "one hit wonders" (I'm using JDBC prepared >statements). So unless something "behind the scenes" is opening transactions >and not closing them, I'm at a bit of a loss. > >One possibility I'm looking into is that my stored procedure may be entering >an "infinite" loop inserting audit trail rows... I can't think of an easy >way to prove this though without using TRACE and getting a log file several >gigabytes in size.... :*( > >Oh well. > > Paul ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------