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
|
I’m planning to use Galera to synchronise the MySQL database that underlies our LightSpeed data model and one of the side-effects of this is that some writes may not have been committed by the time a following read is requested. Most of the time this is fine but there are some parts of our applications which need to ensure reads are consistent with the very latest data. Galera offers a session variable to enable a mode that enforces consistent reads by delaying SELECT statements until all pending commits have been applied so I’m trying to work out how that fits with our LightSpeed code. In terms of raw SQL, we can set the variable using “SET global wsrepcausalreads=1;” Would Query.RawSql be appropriate in this case? Thanks, Chris Edit: On second thought, it doesn't make sense to manage this session variable during SaveChanges() since the behaviour change relates to reads rather than writes. |
|
|
In general using a raw ADO.NET command object is the best approach for executing specific database commands like this, you can use UnitOfWork.PrepareCommand to attach the command object to the connection which LightSpeed is using for that UnitOfWork instance.
|
|
|
That looks promising Jeremy. Sorry for the slow reply. I've just checked in the user guide and confirmed that "The unit of work opens the connection the first time it needs to talk to the database" so I'm wondering how this fits with the idea of issuing database commands against the connection that the UnitOfWork manages. Should I just check the raw ADO.NET connection open state and issue an open request unless it's already been opened by LightSpeed? Will LightSpeed cope with this pesky 3rd party code manipulating the connection state without its knowledge? Thanks, Chris |
|
|
I am now thinking that I'll need to implement a custom connection strategy so that I can deal with timeout and deadlock exceptions neatly. Maybe this session variable management can/should/must be incorporated into the custom connection strategy implementation? |
|
|
Yes using a custom connection strategy would be the best approach as this will ensure you have it set as part of a connection being opened when LightSpeed requires one. In terms of "manipulating the connection state", we do expect the connection to be open (although using a custom connection strategy gives you the ability to detect and cater for such problems as well).
|
|
|
For the record, I've made a custom connection strategy and along with the method below, consistent reads are working as expected in our test Galera/MariaDB cluster.
|
|