From: Jason C. (JAC2) <ja...@ja...> - 2002-12-12 08:44:02
|
Just 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. 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 :-). 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. "Marco Menardi" <mm...@ly...> wrote in message news:at7p45$anb$1...@ne...... > What about a paramter for the transaction? I mean, each transaction can > optionally specify the maximum duration. But I think that could be done > at "client side" too, with some properties in the connection compoents. > And I think that's precisely what IBO (www.ibobjects.com) native > components do: > from the help of TIB_Transaction.TimeoutProps ... > ... > ForceClosed > This property determines the period in seconds IBO will wait before it > forces a transaction to end, without regard for user activity. > > PromptUser > This is the point in time that IBO will actually get intrusive about > prompting the user to get on with their work and get the transaction closed. > > PromptUserDuration > Period in seconds between IBO's prompts to the user to resolve the > outstanding transaction. > > PromptUserRetry > Amount of time in seconds that IBO waits before retrying prompting the > user to resolve their transaction. > ... > > regards > Marco Menardi > > Christian Pradelli wrote: > > Hi! > > > > Dealing with my application to see that any transaction keeps open during a > > long time, I think, is not possible to put a parameter in the configuration > > file to set a Max transaction duration?. > > This would be important because may be I'm a good developer and I do the > > best client-server application, but if a user open an administration tool, > > put a table in edit mode and keep it open.... > > With a feature like this we could guarantee the performance of Firebird > > separating it from bad software design. > > > > I'm right? > > > > best regards christian > > Christian > > > > > > > > > > ------------------------------------------------------- > > 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 > |