Is there a way to associate a web service transaction to a transaction managed by LLBLGen so that a transaction can span multiple service calls? I'm having an issue now where that would come in very handy. Any help is appreciated. Thanks. Eric

I'm not aware of that, though that's because I haven't looked into webservice transactions specifications. Do you have any link to an explanation how these work? I can then tell you if it will work and if not, how to enable it. Thanks.

The specification is WS-Coordination. A link to the specification is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-coordination.asp It's used for distributed transactions. A context id can be set and I was hoping we might be able to get a transaction id from llblgen generated code so that transaction could span multiple service calls. Let me know. Thanks for the help. Eric

My confusion is about 'who coordinates the transaction?'. The main thing with a transaction is: the coordinator is the only object which can commit or rollback physically a transaction. So if I define a COM+ transaction, the MS DTC coordinates the transaction, and makes sure the transaction is committed in all participating services, like sqlserver, sap and what have you.

I see they defined a coordinating service as well, but has that service the authority to rollback an oracle transaction? I don't see how, even if oracle enlists itself as COM+ transactional service.

So IMHO it comes down to: you have different services, each perform a transaction and wait for the message from the controlling service to commit/rollback their own transactions, but this isn't safe, as what happens if service 3 chokes on an error while committing its transaction? How can the coordinating service make service 1 and 2 undo their commits? This can only be done if the physical services like SqlServer or Oracle, Sap obey a hard commit/rollback from the coordinator, i.e. how it's done with COM+.

Could you please shed some light on that please?

Otis wrote:

Could you please shed some light on that please?

Distributed transactions have always been a bitch... The architect community is torn between SOA's "compensation" approach vs. WS-* "WS-Transactions" and "WS-Coordination" approach.

Personally I don't beleive that remote services should be allowed to hold locks on a local resources. The concerns are endless but include performance and security (denial of service becomes easy).

I favor the compensation model where services go ahead and commit local transaction as normal, but included in the transaction, the systems also records an UNDO operation. In the event of a failure in one of other services, each service is simply asked to perform the undo on the relevant transaction they have already committed. Obviously there are more issues here than meet the eye including phantom reads on pseudo committed data and an even bigger issue of how do you undo a delete ...

The positives of this approach include the fact that there are no locks held and if failures are infrequent, then this performs exceptionally well. You just have to get the compensation framework right and your laughing.

In my project I successfully use the compensation model with LLBLGen but as you can probably tell, LLBLGen simply does what it does best "OR Mapping" and the rest is up to you.

Marcus wrote:

Otis wrote:

Could you please shed some light on that please?

Distributed transactions have always been a bitch... The architect community is torn between SOA's "compensation" approach vs. WS-* "WS-Transactions" and "WS-Coordination" approach.

Personally I don't beleive that remote services should be allowed to hold locks on a local resources. The concerns are endless but include performance and security (denial of service becomes easy).

Same here.

I favor the compensation model where services go ahead and commit local transaction as normal, but included in the transaction, the systems also records an UNDO operation. In the event of a failure in one of other services, each service is simply asked to perform the undo on the relevant transaction they have already committed. Obviously there are more issues here than meet the eye including phantom reads on pseudo committed data and an even bigger issue of how do you undo a delete ...

heh indeed, sounds like fun, such an undo operation .

The positives of this approach include the fact that there are no locks held and if failures are infrequent, then this performs exceptionally well. You just have to get the compensation framework right and your laughing.

Which is impossible IMHO: a transaction which is 'somewhat' atomic is IMHO not reliable. Of course, if failures are infrequent and IF a failure is happening, it can be corrected, it's fine.

Otis wrote:

heh indeed, sounds like fun, such an undo operation .

Is is

Otis wrote:

The positives of this approach include the fact that there are no locks held and if failures are infrequent, then this performs exceptionally well. You just have to get the compensation framework right and your laughing.

Which is impossible IMHO: a transaction which is 'somewhat' atomic is IMHO not reliable. Of course, if failures are infrequent and IF a failure is happening, it can be corrected, it's fine.

It all goes back to your requirements... If atomic transactions are required, then you are right, this is not possible using the compensation model. Your best bet is to use COM+ which doesn't fit with the the web service model.

However if you allow yourself to look at services as autonomous, which is one of basic tenents of SOA, then you you have a little more scope for adventure . Data is owned (and governed) by a service. Therefore if 2 services are talking to each other then the idea of an atomic transaction becomes less important. What becomes more important is that each service is happy about the state of its own data at any given moment in time. And the overall key to this is how an application is split into multiple services.

Most developers feel the need to split applications into lots of services (because that's what MS and others, (probably ignorant managers) are recommending). But thats a load of CRAP. Service boundaries are very difficult to get right and are nearly always done incorrectly. The very fact that an atomic transaction is required across a service boundary is IMHO an indication that the service boundary is incorrect.

If you spend a good portion of your design time understanding the data in your domain, you will spot some natural data segmentation. Services in SOA must exploit this natural segmentation in order to correctly determine an appropriate service boundary. An atomic transaction should IMHO never be required across such a boundary and hence the compensation model (including its limitations) fits nicely.

If anyone wants to read up on data segmenation and how this applies to service design, I recommend Pat Helland's article on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dataoutsideinside.asp

BTW - the only way to UNDO a delete, it not to delete in the first place. And if you don't have unlimited storage space, then a higher level 2 phase commit is required to sanction the final delete.

Great overview, Marcus I agree with you on your findings . Let's see at this year's teched how much Microsoft's vision on SOA has changed since their last year's 'everything is a service!!'-mantra