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
|
Hi all, I'm working on integrating Quartz.NET with our current LS implementation (version 2.2). I want to reuse the connections and transactions that the executing thread has. This allows us to reuse all our existing unit and integration test harnesses, as well as allows for consistent commit and rollback behaviour across our application. Quartz.net allows you to specificy a class that returns a wrapper instance of the connection and transaction it needs to use. I've set up this code, however it always gives me this exception I try to open the connection.
System.InvalidOperationException: The ConnectionString property has not been initialized.
Here is my code.
protected override ConnectionAndTransactionHolder GetNonManagedTXConnection() }
If I debug the LightSpeedContext, it is properly configured. Am I simply getting the underlying connection from the wrong source? I'd prefer to use UnitofWorkHolder since I've enhanced it to perform a connectivity test on borrow to elimnate some connectivity issues we were having.
Thanks, Todd |
|
|
DataProviderObjectFactory.CreateConnection returns an uninitialised connection appropriate to the database type specified in the context. It does not set the connection string (you can get this from LightSpeedContext.ConnectionString). It is just a thin wrapper around "new WhateverMyDatabaseIsConnection()". But note that CreateConnection creates a new connection -- it does not return the same connection that the unit of work is using. That's not readily accessible, but you can get at it by implementing a ConnectionStrategy (requires build 12092 or above) or by kludging it (hurrah). To kludge it, create a dummy command (DataProviderObjectFactory.CreateCommand) then call IUnitOfWork.PrepareCommand. The returned command will be associated with the same connection and transaction as the UOW, so you can now retrieve the connection and transaction from the command (and throw the command away). You might want to investigate the ConnectionStrategy route anyway because longer term this could also be a way to handle your connectivity testing and recovery issues (I realise you won't want to change your code for the sake of it, just mentioning it). |
|