The Database Application Block

Hi all,

Can someone please reasure me that it is entirely possible to use the Data
Access Application in large applications - even those that require
transactions?

I have a friend who is adament that the application block is crap because it
uses static methods. He thinks that because its using static methods it is
completely riddled with concurrency holes.

He also believes that it will cock up transactions because it shares a
connection object or something.

I on the other hand am next to certain that the static methods are thread
safe and that transactions are handled correctly shared connection or not.

Can someone please reasure me and my paranoid friend :-) that the *Best
Practice* application block from Micorsoft are actually safe to use in
large, concurrent, transaction based situations without needing vast
amendments.

Many thanks to anyone who can advise.

Take care

Simon

Hi,

it only has static state for parameters (etc DAAB has capability to cache
parameters for procs).

If you look at its code, you'll note it doesn't have a public constructor or
instance methods (cannot be instantiated, cannot have instance state) so
everything happens in a method calls and is released after call ends. E.g
means that multiple threads can call the methods very safely and the calls
won't mix up with each other (everything needed is given as parameter to the
method as is per the idea of static methods)

What comes to the transactions, you need to pass the SqlTransaction object
to DAAB method calls and then the state is kept it that transaction object
(basically)/connection associated with the transaction, not in DAAB.
Therefore transactions work just fine as well, though you'd of course try to
put them as much as possible into database procs themselves and not into
ADO.NET client code, if not necessary. But either way, no problems.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
http://blogs.aspadvice.com/joteke


"Simon Harvey" <sh856531@microsofts_free_email_service.com> wrote in message
news:uu7LNRylEHA.2340@TK2MSFTNGP11.phx.gbl...
> Hi all,
>
> Can someone please reasure me that it is entirely possible to use the Data
> Access Application in large applications - even those that require
> transactions?
>
> I have a friend who is adament that the application block is crap because
it
> uses static methods. He thinks that because its using static methods it is
> completely riddled with concurrency holes.
>
> He also believes that it will cock up transactions because it shares a
> connection object or something.
>
> I on the other hand am next to certain that the static methods are thread
> safe and that transactions are handled correctly shared connection or not.
>
> Can someone please reasure me and my paranoid friend :-) that the *Best
> Practice* application block from Micorsoft are actually safe to use in
> large, concurrent, transaction based situations without needing vast
> amendments.
>
> Many thanks to anyone who can advise.
>
> Take care
>
> Simon
>
>

As Teemu pointed out, there is no problem using the DAAB with large
transacted systems.

Just to add to that: one of the I'm familiar with uses this AB. The number
of transactions is fairly high (10,000 per hour), and the amount of data
being managed is somewhere around 100GB. We've had other load problems, but
not one that is traced to the DAAB.

Really, the DAAB is a convenience... I'm not sure I'd call it a "best
practice" DAL. It's nice, but you will still have to have a smart developer
doing smart things to use it well.

Hope this helps,
--- Nick

"Simon Harvey" <sh856531@microsofts_free_email_service.com> wrote in message
news:uu7LNRylEHA.2340@TK2MSFTNGP11.phx.gbl...
> Hi all,
>
> Can someone please reasure me that it is entirely possible to use the Data
> Access Application in large applications - even those that require
> transactions?
>
> I have a friend who is adament that the application block is crap because
it
> uses static methods. He thinks that because its using static methods it is
> completely riddled with concurrency holes.
>
> He also believes that it will cock up transactions because it shares a
> connection object or something.
>
> I on the other hand am next to certain that the static methods are thread
> safe and that transactions are handled correctly shared connection or not.
>
> Can someone please reasure me and my paranoid friend :-) that the *Best
> Practice* application block from Micorsoft are actually safe to use in
> large, concurrent, transaction based situations without needing vast
> amendments.
>
> Many thanks to anyone who can advise.
>
> Take care
>
> Simon
>
>