SqlMembershipProvider vs. transactions!

[mehdi]

Hi folks,
I've been asking some ASP.NET Membership questions here and there for
the past 8 days (or so) over and over again. But surprisingly, it seems
that no one takes the Membership/role providers seriously - AFAIK. I've
been in a fog for the past week, unfortunately. This is my last try to
solve the real-world problem I've been faced with when using the
ASP.NET Membership APIs or whatever they are called.

In a real-world applications, having a single UserName/Password pair in
a persistent storage (being SQLServer, Active Directory and the like)
doesn't suffice. It is in one way or another, related to some other
entities. For example, in a financial application, it's probably
related to an Employee account where each employee has got one and only
one UserName/Password assigned. Therefore, we will have another entity
to manage (besides the membership information), in this scenario,
Employee accounts.

An employee should never be inserted into the persistent layer if and
only if it's counterpart entity (membership info) is also added to the
persistent layer! i.e., either both or neither! This simply implies
that we need to do things under a given transaction.

However, there's no way to ask a Membership provider to do things
(CreateUser, for instance) under a given transaction and therefore we
cannot keep the integrity of the whole system. Unfortunately, the
Membership methods are all declared as static, therefore, developing a
new SqlMembershipProvider class is not enough since there's no way to
pass the Transaction object to the above-mentioned class.

Any help and/or idea to solve the issue would be highly appreciated,

Thank you for your time,
Mehdi

 

[Dominick Baier]

well - you can do somehting like this:

using (TransactionScope ts = new TransactionScope())
{
Membership.CreateUser(..);
DoSomethingElse(..)

ts.Complete();
}


The Membership class methods are static - not the actual provider. If you
need more advanced functionality, then membership is not designed for that
and you have to write a good old class that does your user-management. If
you need membership because you want to share the implementation between
several other technologies (SharePoint, WCF) - then you have to live with
the interface it provides or find whacky ways to pass more data into it (which
work in one environment or another and kind of defeats the purpose).

 

[mehdi]

Well, thank you for being straight! The following call will end up in
MSDTC, although both connections point to the same SQL Server instance.
Right?

The other question is that whether the "MSDTC" is available on "Windows
XP Home Edition"?

TIA,
Mehdi

 

[Dominick Baier]

right - it will promote to DTC - so the same thing we have been doing for
years

I have no idea if DTC is available on Home Edition - but i assume.