Vikram,

That you for the update.   I've read the communicator article and in
6.5 the maximum transaction limit was raised by a factor of 8.   That
should make the stalled transaction problem a much rarer event.   That
is a big improvement.

To answer your earlier question, no, I don't know of any other
problems with dynamic rollback.

Cortlandt Wilson
Cortlandt Software
Mountain View, CA
(650) 966-8555

"B T Vikram Kumar" <[log in to unmask]> wrote in message
news:39a24e86$1_1@skycache-news.fidnet.com...
> There is a fixed limit for transaction manager (XM) log, which is 64
MB.
> When there are many open transactions in the system, this log file
also
> gets filled up. When the total logsize about 32 MB (this 32 MB limit
is,
> since we may rollback all transactions) , one will again get another
> 'stalled transaction' message, and IMAGE rolls back all
transactions.
>
> The above limits have been increased in 6.5. The new limit for
> transaction size is 32 MB. The default size for XM log size is still
64
> MB. However, this can be configured to higher values using VOLUTIL.
Also,
> direct IMAGE users can have a new DBCONTROL Mode-18. If this call is
made
> before the start of transaction, when the tranasction grows to about
28
> MB in size, IMAGE will send out a softlimit warning message and
inhibits
> any fresh put/delete/updates. On receiving the message, application
can
> either commit or rollback the transaction and proceed. In this way,
one
> can prevent individual stalled transaction. However, if  there are
too
> many large open transactions and XM log size has not been increased,
all
> the open transactions will get stalled transaction message and get
rolled
> back.. See 6.5 Communicator article 'Large Transactions for
IMAGE...'
> (http://docs.hp.com:80/dynaweb/smpe/b1015/5cu/@Generic__BookView)
for
> further details.
>
> Hope this helps
>
> Regards,
> Vikram
>
> Steve Dirickson wrote:
>
> > Thanks for the update. Is the XM buffer dynamically sized by MPE a
s
> > required by demand? Or is it still a fixed (albeit
user-configurable)
> > size that will cause XM to abort the transaction if it fills up?
> >
> > Steve
> >
> > > The problem of small XM buffer has been addressed. Now there
> > > is a large
> > > and configurable XM buffer, and is capable of supporting large
> > > transactions. This solution has gone out with MPE 6.5. I am also
> > > interested in knowing the specifics of  any other dynamic
rollback
> > > problem.
> > >
> > > Regards,
> > > Vikram
> > >
> > > Steve Dirickson wrote:
> > >
> > > > > IMO HP appears to treat the dynamic rollback problem more
like
> > > > > a DBMS limitation than a bug.
> > > >
> > > > Pardon my ignorance: what "dynamic rollback problem" are we
> > talking
> > > > about? The XM buffer overflow is a defect in MPE, not in
> > > the DBMS, so
> > > > I assume this refers to something else?
> > > >
> > > > Steve
> > >
>