Tech Off Thread

13 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

.net sealed

Back to Forum: Tech Off
  • User profile image
    armbrat

    Does anyone know why the SqlDataAdapter class is sealed?  I know that's a pretty general question, but wouldn't it be useful to be able to override some of the functions?

  • User profile image
    RobChartier


    I think the biggest reason for most of the framework to be marked as sealed is the support issues.  If you have a million developers overriding the framework in their own manner and then calling in for support when things dont work right, the MSFT support team would have a nightmare trying to figure out what exactly is done and where exactly does their support role fit.

  • User profile image
    gabe19

    I think the reason would be more to the interests of the class designers. They are forcing you to go up to one level in the hierarchy and use DbDataAdapter, just as they did to implement SqlDataAdapter. Effectively saying - Sql adapter has been done and your design shouldn't include modifications to the way it works internally.

    Most of the methods and properties are inherited from elsewhere in the class hierarchy anyhow. I bet you could get what you want from writing your own adapter off the same base classes used by SqlDataAdapter.

  • User profile image
    armbrat

    I'm asking this because I have a situation where I get database timeouts. 

    I figured I could just tell it to retry a number of times with a random retry delay period.  There's alot of code I need to change, and I figured I could save some work by overriding the Fill method.

    Guess I'll get started with my copy and paste solution...

  • User profile image
    W3bbo

    armbrat wrote:
    Guess I'll get started with my copy and paste solution...


    Or use various MSIL Dissassemblers / Reflectors to peek at the code inside the SqlDataAdapter and build-your-own.

  • User profile image
    gabe19

    Or write your class as IDbDataAdapter, call the adapter more generically from your code, and then wrap your calls to your private SqlDataAdapter, putting some retry code around the Fill method.

  • User profile image
    Vipul

    and what was your final solution?

  • User profile image
    DoomBringer

    gabe19 wrote:
    Or write your class as IDbDataAdapter, call the adapter more generically from your code, and then wrap your calls to your private SqlDataAdapter, putting some retry code around the Fill method.

    design patterns! yay!

  • User profile image
    armbrat

    My final solution?  Cutting and pasting a heck of alot of code...

    I wish I understood how to implement the interface as Gabe19 suggested, but I really don't...

    So, I just wrapped everything as:

    for (int i=0; i<DbRetryCount; i++)
    {
       try
       {
          Adapter.Fill(DataSet, "Products");
          break;
       }
       catch 
       {
          System.Threading.Thread.Sleep(Get_DBWaitPeriod());
       }
    }

    where get_dbwaitperiod gets a random period between a min and max time... say, 50 and 500 ms (which is acceptable to me).  The retry count is set at 2 right now.  Haven't deployed it yet, so I'm not sure if this will solve it.

  • User profile image
    Charles

    armbrat,

    your solution uses a particularly bad pattern (catch-all exception handling...). You should only catch SqlException in this case, else, fail.

    But, generally, you should really try and determine why your SQL tranasctions are timing out. That's where I would spend my time before implementing re-try hacks.

    C

  • User profile image
    armbrat

    Yes, I agree.  I do use proper exception handling elsewhere, not sure why I didn't here...  Must have been rushing/watching the clock hit <<insert late time here>>.

    I have no idea why I'm timing out.  I have multiple machines all running the same server program.  When they are all hitting the same table, that's when it happens.  I wish I could explain it more, but I think I'd get in trouble from the boss Tongue Out

    One idea I had was to implement table locking using the database.  I hit each table sequentially (update table a, then b, then c, etc...) so writing code to wait for exclusive access to the table is an option, but one I was hoping to avoid.  I don't even know if this is a common/proper method to use.

    I dunno.  Sometimes I wish I had someone who could come in and look at my code and my methodology.

  • User profile image
    Charles

    Are you using stored procedures? How big is this table? How is it designed? You are only hitting one table???

    Basically, you do not want to use (nolock) on table Updates. However, for reads, it's a good idea...

    SQL is rather good at concurrent transactions... Your code and/or DB design is the problem.

    Can't help you without more info.

    C

  • User profile image
    armbrat

    Well, the database design is very well thought out.  It was designed by a seasoned vet (not myself).  I am hitting one table at a time during updates.  For example:

    - update table1
    - update table2
    - update linking table between 1 and 2

    These tables are pretty large.  They are all id'd using unique ids.  They are holding > 100k records each and updating ~10K per update.

    All my calls are using stored procs.  My business logic is in code, not in the stored proc. 

    I was using .net Sql transactions, but was having problems when multiple apps were running the same set of code on different servers.  So, I decided that since all my table access is sequential, I don't really need the transactions.  Plus, the data I'm publishing can be recreated, so I don't really care if the data update dies half way through.

    My idea for the table lock would be:
    - Acquire lock from a locking table in the database.  Ie, UPDATE TableLocks SET IsLocked = 1 WHERE TableName = 'Table1'
    - Do the business on the locked table
    - Free the lock from the locking table.

    Right now that's my idea.  Is that enough more info?  My terminology is probably a little off, but I think you can get the idea.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.