Re: [Firebird-net-provider] Question for .NET Provider Author re transaction conflict

[Helen B. <he...@tp...>]

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