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
|
Hello, I have a very strange lock problem using VistaDB and LS 3.11 (10-2-2011 nightly build). The test database contains 3 very simple tables:
Then I try to run a unit test. This test will insert a new Analyte and then delete all the new data that was inserted in the DB (the example is idiotic, but the idea is to clean the DB after each test run). This is the test code:
[TestMethod]
The test crashes in the command.ExecuteNonQuery() line, and the error given by the test runner is: Test method LockProblemTests.FileImportOperationsTests.Verifies_Import_CSV_does_not_throw_exception threw exception: But if I make the fk from Analyte to AnalyteType nullable, and remove the call to unitOfWork.FindOne<AnalyteType> then the test runs perfectly, which has me completely puzzled. I have to admit I have no idea where the problem is or if it's a problem of concept with my approach to this :( Regards, Vicente |
|
|
I don't know if this will fix your problem, but you should try disposing the IUnitOfWork before opening a new connection. At the moment, the connection opened by the IUnitOfWork is still open when you open the ADO.NET connection. This could be causing the locking issue, and at the very least you'll want to eliminate it as a possible cause. |
|
|
Hi Ivan, disposing the UoW does solve the locking problem. I can do this in the tests, but in our main WPF app the pattern I'm using is having a single unit of work that lives during the whole application lifetime, so if that problem hits us there we may have to rethink a lot of things :S Regards, Vicente |
|
|
You would probably be okay if you did the ADO.NET work over the same connection that the UOW is using, rather than a separate connection. To do this, use IUnitOfWork.PrepareCommand to associate your Command with the UOW's connection (and transaction if any). See http://www.mindscapehq.com/forums/Post.aspx?ThreadID=2619&PostID=7945 and http://www.mindscapehq.com/forums/Post.aspx?ThreadID=2390&PostID=9734 for examples (though I just spotted a typo on the 'crucial line' in that second one *sigh*). |
|
|
Mmm, I have tried the following:
using (IDbCommand command = unitOfWork.PrepareCommand(unitOfWork.Context.DataProviderObjectFactory.CreateCommand()))
And I get the following exception: Test method LockProblemTests.FileImportOperationsTests.Verifies_Import_CSV_does_not_throw_exception threw exception: But if I put the code inside the transaction, and not outside the transaction (as it was originally), then it runs. Any tip why? |
|
|
Hmm, this is down to an unfortunate interaction between LightSpeed and VistaDB. It seems that although the transaction has completed, we still have a record of it and PrepareCommand still attempts to enrol the command in it. Most database providers appear to ignore this. But VistaDBCommand responds by resetting its Connection to null, causing the error you've observed. I will implement a fix for this and it will be in the next nightly build. |
|
|
Thanks a lot Ivan :) |
|
|
Hi my mainainence expired on Feb 2nd. Is there anyway I could get the build that has this fix in it? |
|
|
We've extended your maintenance temporarily so you can get this fix, but it would be a good idea if you renewed as soon as possible in case you run into any further issues. You'll get a 50% discount if you renew within the extension period (i.e. within the next 48 hours or so); after that it will revert to normal renewal pricing. |
|
|
We went and extended our maintainence. Is there any reason why we couldn't have two different contexts accessing the same table at the same time and not get locking issues. When we used to use ado.net we didn't have nearly as many locking issues as when we switched over to lightspeed with multiple threads accessing the same tables at the same time. |
|
|
We're just using ADO.NET under the covers so there's no reason you should see more locking issues with LightSpeed than with ADO.NET. It may however be a matter of transaction management: LightSpeed uses transactions to ensure atomicity, which VistaDB probably handles using locks, and your ADO.NET code may have made less use of transactions. Ensuring that units of work are disposed promptly may mitigate this. If that doesn't help we'd be happy to work with you and the VistaDB folks to try to identify how we can improve our transaction handling on VistaDB -- we'd probably need to get a simple console project off you that replicated the issues. |
|
|
Ivan - On behalf of VistaDb, thanks for looking into this. Please contact me directly if we can be of assistance with helping your customers use VistaDB effectively! I've added a note to our system around this corner case behavior to see if we can, at a minimum, raise a better error to illuminate what's going on and help with diagnosis. |
|
|
Why is IUnitOfWork holding a lock anyway? If it is not actively accessing the database? |
|
|
ivan, kendallmiller I don´t have here the test case that was giving this problem (I´m out of Spain, so I don´t have my main dev machine). Once I get back (in a few weeks), I´ll test again with the latest builds of both products and post in both forums. Thanks for your time. |
|
|
[quote user="terricide"]Why is IUnitOfWork holding a lock anyway? If it is not actively accessing the database?[/quote] It isn't -- at least not directly. However, when Vicente calls BeginTransaction(), the UnitOfWork passes that on to VistaDB, which evidently implements the transaction by locking. The issue is what happens when Vicente disposes the transaction. We believe we are passing that on to the ADO.NET database provider, which should release its locks at that point. So either (1) we are not passing it on to the database provider, or (2) the database provider is not releasing its locks when the transaction is disposed, but is instead holding them until the connection is disposed. If it's (1), then obviously that's a bug in LightSpeed. But we're pretty sure that's not the case. If it's (2), it's unfortunately out of our control. Fortunately kendallmiller from Gibraltar Sofware is monitoring this thread and has indicated that they're keen to work with us and our customers on understanding and resolving any issues you run into. Your multithreading issues may be related to Vicente's spurious lock, or it may not -- we don't really have enough info. So if you can provide us with a repro of the contention issues you're seeing then we'll try to disentangle the LightSpeed bits from the VistaDB bits and flag up any VistaDB-side issues to the Gibraltar folks. |
|