From: MartinT <mar...@ya...> - 2008-04-16 21:28:51
|
Hello there I am using IBReplicator (a Firebird replication application) and I have been experiencing some problems with our software locking whilst replication is happening (on a separate scheduled process). I contacted the IBReplicator developer to ask whether their software locks any tables. Here is the reply I got: "...I think that you should consult with .net provider's author whether transaction with his default params can conflict with standard "concurrency nowait" transaction..." So I am humbly asking you for help here in the hope that I can get to the bottom of our problems. Many thanks. -- View this message in context: http://www.nabble.com/Question-for-.NET-Provider-Author-re-transaction-conflict-tp16733863p16733863.html Sent from the firebird-net-provider mailing list archive at Nabble.com. |
From: Jiri C. <di...@ci...> - 2008-04-16 21:45:28
|
On 4/16/08, MartinT <mar...@ya...> wrote: > I contacted the IBReplicator developer to ask whether their software locks > any tables. Here is the reply I got: > > "...I think that you should consult with .net provider's author whether > transaction with his default params can conflict with standard "concurrency > nowait" transaction..." > > So I am humbly asking you for help here in the hope that I can get to the > bottom of our problems. When you didn't specified any isolation level, then default is ReadCommitted from .NET's POV. To the database (in TransactionParameterBuffer) is sent - Write + Wait + ReadCommitted + NoRecVersion (I hope you can decode what it means in "server's language", for more info you can look to IscCodes file). -- Jiri {x2} Cincura (CTO x2develop.com) http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com |
From: MartinT <mar...@ya...> - 2008-04-16 22:35:08
|
Jiri Cincura wrote: > > When you didn't specified any isolation level, then default is > ReadCommitted from .NET's POV. To the database (in > TransactionParameterBuffer) is sent - Write + Wait + ReadCommitted + > NoRecVersion (I hope you can decode what it means in "server's > language", for more info you can look to IscCodes file). > hi. and thanks for the reply. does this mean it could conflict with a standard "concurrency nowait" transaction, as the man suggests? -- View this message in context: http://www.nabble.com/Question-for-.NET-Provider-Author-re-transaction-conflict-tp16733863p16735081.html Sent from the firebird-net-provider mailing list archive at Nabble.com. |
From: Helen B. <he...@tp...> - 2008-04-16 23:49:11
|
>Jiri Cincura wrote: >> >> When you didn't specified any isolation level, then default is >> ReadCommitted from .NET's POV. To the database (in >> TransactionParameterBuffer) is sent - Write + Wait + ReadCommitted + >> NoRecVersion (I hope you can decode what it means in "server's >> language", for more info you can look to IscCodes file). >> At 08:34 AM 17/04/2008, MartinT wrote: >does this mean it could conflict with a standard "concurrency nowait" >transaction, as the man suggests? Exactly so. Writers block readers under these conditions. Helen |
From: MartinT <mar...@ya...> - 2008-04-18 00:39:57
|
Helen Borrie wrote: > > Exactly so. Writers block readers under these conditions. > Helen Thanks for your reply. You have always been so helpful in the past, and I am very grateful for that. It is good that I have identified the reason why our software is locking. Scheduled 'behind the scenes' replication is very much a feature I would like to keep. Yet at the same time it is unacceptable for our software to lock each time this happens. I am unsure of what my options are here. Should I consider changing the isolation level for our transactions? Will this only create different problems? Your advice would be much appreciated. Many thanks. -- View this message in context: http://www.nabble.com/Question-for-.NET-Provider-Author-re-transaction-conflict-tp16733863p16758487.html Sent from the firebird-net-provider mailing list archive at Nabble.com. |
From: Helen B. <he...@tp...> - 2008-04-18 02:56:51
|
At 10:40 AM 18/04/2008, MartinT wrote: >Helen Borrie wrote: >> >> Exactly so. Writers block readers under these conditions. >> > >Helen > >Thanks for your reply. You have always been so helpful in the past, and I am >very grateful for that. > >It is good that I have identified the reason why our software is locking. >Scheduled 'behind the scenes' replication is very much a feature I would >like to keep. Yet at the same time it is unacceptable for our software to >lock each time this happens. Agreed. It's always a source of mystery to me why driver developers, more often than not, provide the worst possible settings for the default transaction. The .NET Provider isn't alone in this: most of the Delphi component sets do the same. I'm not sure about the Jaybird and ODBC drivers these days. Maybe it's driven by the Microsoft World View, somehow, you know, standardise all database back-ends on the Excel model? ;-) >I am unsure of what my options are here. Should I consider changing the >isolation level for our transactions? Of course. If you are using the .NET Provider's defaults then you have applications that were written for a single-user desktop system, not for a client/server network. This "dumbing down" makes life simple for a while. It's a sad fact that application designers often don't think about scaleability until about 10 minutes after the very first occasion when new requirements require scaleability!! Replication happens to be the thing that has socked you between the eyes; for others, it might be a monthly reporting suite or a busy day with a batch data collection process coming online that sends everyone off for a day at the beach. >Will this only create different problems? For the developers, yes. They'll need to get their thinking caps on (= EFFORT) but, if they get it right, the users won't notice any difference. Bear in mind that terms like "multi-user-friendly" and "scaleable" are totally in the application designer's preserve. The database engine itself provides for both. The .NET Provider driver provides what the developer needs to access those capabilities. The moment when new requirements broaden the horizon is probably not a moment too soon for the developers to get their heads around what's lurking there besides the defaults... Helen |
From: Dean H. <dea...@dl...> - 2008-04-18 03:06:52
|
Helen Borrie wrote: > Agreed. It's always a source of mystery to me why driver developers, more often than not, provide the worst possible settings for the default transaction. The .NET Provider isn't alone in this: most of the Delphi component sets do the same. I'm not sure about the Jaybird and ODBC drivers these days. Maybe it's driven by the Microsoft World View, somehow, you know, standardise all database back-ends on the Excel model? ;-) I believe the settings are the equivalent of SQL Server's "READ COMMITTED" settings, which is the default for .NET Data providers. Dean. |
From: Madhu S. M. <mad...@gm...> - 2008-04-18 13:49:31
|
Dean Use this http://www.firebirdsql.org/dotnetfirebird/blog/2005/02/transaction-isolation-levels-in.htmlas a reference. ] Madhu |