Re: [Firebird-devel] Max transaction duration

[Christian P. <c_p...@ya...>]

finally somebody understand which is my point!! :)

"David Jencks" <dav...@di...> escribió en el mensaje
news:20021212201712.Q14852@HP.home.home...
> On 2002.12.12 19:26:10 -0500 psc...@in... wrote:
> > On 12 Dec 2002 at 8:25, Jason Chapman (JAC2) wrote:
> >
> > > Just my thoughts.
> >
> > How about my thoughts....
> >
> > >
> > > The main reason for this feature is to cope with software that hasn't
> > > been written in a sympathetic way towards sensible transaction length,
> > > so implementing in the client seems weaker than having a _database_
> > > parameter.
> >
> > The software should be fixed, a maximum transaction duration, cures the
> > symptom,
> > and not the overall disease, a badly designed app, which probably has
> > other
> > problems as well.
>
> NO!!  The purpose of timeouts is not to compensate for badly written
> anything, it is to make it possible to write robust distributed programs
> that can continue operating even when some parts crash or become
> unavailable.  If someone removes the lan cable between your well written
> app and the firebird server, either firecbird has to be able to recognize
> that your uncompleted transactions can be rolled back, or some person will
> have to do it.
>
>
> >
> > > Also, units of time do give users the most consistent interface (i.e.
> > > it would become known that 24 hours and your app will be rolling back
> > > all over the place), but from a true protection perspective it would
> > > be better to do this for the difference between transaction numbers
> > > e.g. next TX - theTX >= 500,000.   Could you imagine someone realising
> > > that the date on the server is a day out, adjusting it & all users get
> > > their TX's rolled back :-).
> >
> > There are a couple of issues, any overall general transaction life
> > routine, will either
> > need too long a period that a transaction can live, or it's going to
kill
> > something
> > important.  For example if the year end sales report runs for 17 hours,
> > then you
> > need to set the timeout to at least 18 hours.   This means that ANY
> > transaction can
> > live for 18 hours, if you have 25,000 normal transactions an hour, your
> > still sunk.
> >
> Specify the timeout per transaction.  Personally I think the JINI idea of
> renewable leases is the most elegant, but simple timeouts are standard in
> the database world.
>
>
> > Next, whether caused by a sales report, or a duffus playing around, the
> > performance
> > effect is the same, that long running transaction, is going to gum up
the
> > works.
> > Ultimately the application needs to be changed to use more shorter
> > transactions.
> >
> > > Also I think that it should kill the connection and not just the
> > > transaction as then the offending application will cease, as opposed
> > > to one element of it ceasing to work (the client will probably not
> > > know the tx has been rolled back & I review plenty of code where
> > > unusual exceptions are just swallowed). Also it should put an entry in
> > > the log file.
> > >
> > > Finally, this should really be considered a bug in the client
> > > application and to add to the debugging the ultimate would be stats on
> > > Open TX's with connections and IP addresses etc.
> >
> > I think a better solution, is when you create a transaction, you can
> > identify the
> > application, the engine then has a duration, but it doesn't kill the
> > transaction or the
> > connection, but it does write an entry in it's log that transaction xxxx
> > owned by
> > application yyy exceeded the transaction limit of zzzzzz ms.   This way
> > when
> > transactions are causing problems by running too long, the DBA can
notify
> > the
> > proper person and the application can be fixed.
>
>
> Hardware failures are not always caused by bad programming.  Why make the
> poor dba figure out how to recover when firebird can do it just fine
> itself?
>
> david jencks
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Firebird-devel mailing list
> > Fir...@li...
> > https://lists.sourceforge.net/lists/listinfo/firebird-devel
> >
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Firebird-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>