This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Microsoft has outlined the methods for dealing with SQL Azure using the The Transient Fault Handling Application Block. Is there an easy way to use this with a Unit of Work? |
|
|
|
|
Here are some details of how you can make this work with the application block - YMMV - http://brendenc.com/?p=15 The other approach you can take (not using that application block) is to implement a custom connection strategy which checks the connection for a fault on each use and handles the re-connection. There are some details in the docs about how to get going with this - http://www.mindscapehq.com/documentation/lightspeed/Building-Applications-with-LightSpeed/Customising-How-LightSpeed-Connects-to-the-Database
|
|
|
|
|
The first option is not really an option for us as we are moving an existing system and rely heavily on LINQ and do not have the time to rewrite all of our queries in order to place them inside a retry block. We have attempted to implement our own custom connection strategy. We were thinking that as a custom ConnectionStrategy returns an IDbConnection we could create our own DbConnection that returns a custom connection (that uses ReliableSqlConnection). When CreateCommand on this custom connection is called we would return a custom IDbCommand. If we can implement this then we can intercept calls to ExecuteReader and the like and replace them with calls to ExecuteReaderWithRetry from here. This does not work however. Down in the depths it is required that the connection returned is an DbConnection. If we create a custom subclass of this we get a type cast exception as our custom connection class can not be cast to a SqlConnection. (In UnitOfWork.PrepareCommand) Is there any chance you guys are thinking of implementing the ReliableSqlConnection provider? The other question I suppose I have is, would the source be easy to modify in this regard? How many references to SqlConnection are there as opposed to the base class DbConnection or (even better) the interface IDbConnection? |
|
|
|
|
No we are not intending to implement this as a provider. Modifying the source is certainly an option for this and it would certainly give you scope to implement your own provider or modify an existing one to fit your needs. Please keep in mind we cant provide any support for any custom implementations. In terms of references to SqlConnection, there is only 1 reference which is where we have to construct a new instance of one and this is isolated to within the base SQL Server provider implementation. We keep the underlying typed instances boxed inside the provider implementations and deal in IDb equivalents outside of the provider specific code.
|
|
|
|
|
Thanks Jeremy, We will probably have to take this option (modifying the source). Very happy to hear that there is only one reference to SqlConnection. |
|
|
|
