Re: optimal size for rollback

>
>
> You must be another one working with an App. that doesn't permit data to be
> altered unless it automatically throws in a 'commit', huh?
>
> I think you're in a minority on that one. A "proper" app. should allow the
> user to modify data, look at it, check it, re-check it, and when they're
> ready, click a 'save' button or something similar to issue the commit. Any
> app. that doesn't do that is waltzing all over the transactional model.
>

Hmm, you certainly have the point that such design is legitimate. But I cannot agree that this is the only "proper" design possible. For every such implementation
there should exist a way to implement this without leaving a transaction hanging

around. I think there are reasons they don't use this approach, and, by doing so,
misuse the transactional model. Reasons could be web-related issues, locking issues, or mentioned rollback segment problems.

I actually think that I am in the majority, whether I care about it or not.

>
> > I do not think that it really suffers.
>
> I'm afraid that what you think and what actually happens are, in this case,
> two different things. And .. the cost of a shrink does indeed come mainly

> from the data dictionary manipulations required to give it effect. So

in LMT, that cost is hugely reduced. But it's not nothing, even so.

I would like to see some performance-related numbers or some theoretical proof. Something more than just "because I say so". It is obvious that it will have some
effect when it is present and transactions will be faster when it is absent. I question
the existence of the performance hit. You are welcome to prove me wrong.

>
> This is complete horse-manure too.

Please try to control yourself ...

Regs
AK Received on Sat Sep 21 2002 - 01:53:12 CDT