Good day all,
I'm still fairly new to CSLA.NET, and OO for that matter, so please bear with me. I have a BO that when used in most situations work exactly a I expect it to. I have the Transactional Attribute set to TransactionScope on my DataPortal delete, insert and update functions. However, when I start a TtransactionScope in my application, and make multiple calls to the BO to insert rows, it does not seem to become part of the existing transaction.
I am using the Wcf Remote Data Portal, and I though maybe the transaction is somehow not being taken along to the server from the client, but I'm not sure how to check that.
Am I missing something obvious, or is there a trick to this.
David
Hi Kevin,
Maybe I'm not explaining myself very well. I need to have the BO updates/inserts happen as part of a bigger transaction which involves other resources. Therefore I have to start and end the Transaction, but the way I understood it, was that with TransactionScope, anything that can join transaction will do so if their is an ambient (read active) transaction.
Hope this makes it a bit clearer.
David
The data portal does not enlist transactions between client and server, at least not by default. If it is possible, it would be by configuring WCF appropriately.
WCF doesn't enlist transactions between client and server by default either. There is the WS-Transaction spec, and if WCF supports that (and it may) then you might be able to configure WCF to enlist the transaction across the connection.
I don't know how that works, as I've never done it. Somehow you'd need to link the thing into the DTC or some other transaction coordinator, so you'd probably have to enable the DTC on all clients and servers involved. There's a pretty major performance/scalability impact to doing something like this, but if you have relatively few users and they aren't in a hurry it might work.
Thanx Rocky,
I suspected as much. I defnitely know that it is possible to propagate transactions across WCF, I probably just misunderstood your discussions about transactions, and transactionscope in your book, to mean across client and server, and not just the current scope of the update/insert, etc on the server.
That means some more reading for me, and looking in some more detail as to what exactly is required. Or maybe I should relook at my design, and see if I really need the transaction to be as wide as it is.
Will post my findings back here.
Regards
David
As a general rule it is a terrible idea to allow transactions to
span a client-server connection, or even a server-server connection (beyond app
server to db server). The performance ramifications are usually very high, and the
fragility of the overall system also goes up radically (transaction timeouts,
cascading locking, etc).
Rocky
Copyright (c) Marimer LLC