So, I'm testing 5 cases per second and seems to be, that I'm little
bit confused with TransactionScope and no result. :)
To clarify things I'll do some summary. Focused on some basic ADO.NET
classes. If you're writing some objects, that will later bind to so
visual components you'll probably use FbXxx objects directly.
* Filling dataset using tableadapters.
I don't care, whether it's done in one transaction. It'll be tested
during update (see below).
SqlClient:
TransactionScope block is there.
Enlist=True ==> with DTC all tables filled, without DTC only first
Enlist=False ==> all tables filled
Pooling has probably no impact (I've not registered any).
TransactionScope isn't there.
Enlist=True ==> all tables filled (DTC has no impact)
Enlist=False ==> all tables filled (DTC has no impact)
Pooling has probably no impact (I've not registered any).
Now FbClient:
TransactionScope block is there.
enlist=true;pooling=false ==> all tables in DataSet are filled
enlist=true;pooling=true ==> only first is filled
enlist=false;pooling=true ==> all tables filled
enlist=false;pooling=false ==> all tables filled
Can be considered as good, except the second case. It's IMO problem.
AFAIR it's because our implementation of enlisting.
TransactionScope isn't there.
enlist=false;pooling=false ==> all tables filled
enlist=false;pooling=true ==> all tables filled
enlist=true;pooling=true ==> nothing is filled
enlist=true;pooling=false ==> nothing is filled
The third and fourth case is IMO problem. Why??? IMO we have two
choices. When enlist is true and no TS block, throw exception (not my
favourite) OR just ignore the enlisting and do it without "thinking"
(my favourite).
* Updating ...
This is really more interesting topic. :)
I'm updating all two tables, as a worst case for provider.
SqlClient (don't care about pooling, it's probably irelevant - if
somebody thinks another, let me know):
TransactionScope block is there.
Enlist=True ==> without DTC it fails (on second update), with it works
as expecting
Enlist=False ==> works as expecting - ignoring the TransactionScope
and doing the stuff without explicit transaction handling
TransactionScope isn't there.
Enlist=True ==> working (as expected)
Enlist=False ==> working (as expected)
And now FbClient:
TransactionScope block is there.
enlist=true;pooling=false ==> works as expecting
enlist=true;pooling=true ==> not working, Exception (line 469) in
FbDataAdapter: Unable to enlist in transaction, a local transaction
already exists
- when the connection of one TableAdapter is opened by hand, it works
enlist=false;pooling=true ==> not working under TransactionScope
(every table change is immediatelly commited)
enlist=false;pooling=false ==> same as enlist=false;pooling=true
TransactionScope isn't there.
enlist=true;pooling=false ==> NullReferenceException on line 469 of
FbDataAdapter
enlist=true;pooling=true ==> same as previous
enlist=false;pooling=true ==> no problem
enlist=false;pooling=false ==> no problem
I think there's a room for improvements. We should talk about this and
see what behaviour will fit most needs (something isn't possible
'cause we don't have DTC).
--
Jiri {x2} Cincura (Microsoft Student Partner)
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
