Wondering if anyone has gotten the infamous "database is locked" error from Trac and how you solved it. It is starting to occur more and more often for us. Will we really have to bite the bullet and migrate to a different DB backend, or is there another way?
See these two Trac bug entries for more info:
http://trac.edgewall.org/ticket/3446
http://trac.edgewall.org/ticket/3503
Edit 1 Thanks for the answer and the recommendation, which seems to confirm our suspicion that migrating to PostgreSQL seems to be the best option. The SQLite to PostgreSQL script is here: http://trac-hacks.org/wiki/SqliteToPgScript Here goes nothing...
Edit 2 (solved) The migration went pretty smooth and I expect we won't be seeing the locks any more. The speed isn't noticeably better as far as I can tell, but at least the locks are gone. Thanks!
That's a problem with the current SQLite adapter. There are scripts to migrate to postgres and I can really recommend that, postgres is a lot speeder for trac.
They just fixed this on Sept 10, and the fix will be in 0.11.6.
http://trac.edgewall.org/ticket/3446#comment:39
I don't think this is 100% fixed just yet. We experience this error a couple dozen times a day. In our case, we have 30+ people updating Trac constantly as we use it for tracking pretty much everything, and not just bugs. From ticket #3446:
Quite obviously, this is [...] due to
our database access patterns... which
currently limit our concurrency to at
most one write access each few seconds
Related
has anyone had any/know of any issues with ibatis submitting several duplicate queries?
we have been seeing (intermittently) the same sql statement being executed up to 5 times. Originally we thought we were dealing with over zealous click happy users, but we freeze the submit buttons to prevent multiple clicking and we still get this.
I seem to remember reading somewhere that this is a bug in ibatis, but i cant find it again (or maybe i dreamt it, my dreams are often weird).
Thanks
Are you talking about this?
https://issues.apache.org/jira/browse/IBATIS-369
They say the bug is fixed.
Most (if not all) of existing migration tools think that migration history is linear. So when you create new migration, you get version 42 or whatever, and then everybody can update to this version after receiving your changes.
The problem is that if you are using DVCS, two people could have version 42 in the same time. Which means that conflict resolving will become sufficiently non-trivial to be painful. :)
So my question is - should I roll my own system or is there anything in the wild? Preferably simple, friendly to *nix. I'm planning to use this mostly with mysql and postgresql.
In Rails, the way this gets handled is by appending the date to the beginning of the file, in the form of YYYYMMDDHHMMSS_migration_descriptor.rb.
It then keeps track of which migrations have been applied in a table, by keeping track of the version numbers. This allows you to run migrations on a table with a "lower" version number than the most recent change, thus greatly simplifying DVCS problems.
You might not be using Rails, but I think the way they solve this problem is pretty nice. You can read more about Rails migrations on the API docs, or on the Rails guides.
I have an application I'm porting from MSSQL and .NET to SQLite and Mono. I'm using NHibernate, FluentNHibernate, NHibernateLINQ and SQLite.
When I test the application with only one person connected everything works OK, but the moment somebody else starts using the app it breaks and throws an SQLite Exception saying "Database File is Locked".
I know that SQLite locks the database when a write is being made and returns a busy status, I'm guessing maybe I haven't configured NHibernate correctly to handle this, but I can't find any information online that has helped so far. It's like I'm the only person with this problem. Am I ? Any ideas ?
Thanks
I suspect your problem is not FNH per se.
I had a similar problem in my FNH / SQLite project (.NET, not Mono). It mysteriously fixed itself after I refactored some of the session management code for other reasons. (The main changes were to use Transactions for ALL DB access, and to ensure all Transaction and Session objects were properly Disposed).
This link discusses a similar problem that was caused by a missing Dispose. I suspect that may have been my problem, but am not sure. (Just keeping my fingers crossed that the problem does not reappear!).
Another good source of things to try is Database file is inexplicably locked during SQLite commit
In essence this is a followup of this question. I'm beginning to feel that I should give up the whole idea, but I'll give it one more shot.
What I want is pretty much like a DB transaction. It should track my changes to the DB and then in the end allow me to either commit or rollback them. If I insert an object, I should get it back in my next (appropriate) SELECT query. If I delete it, future SELECT queries should not return it. Etc.
But there is one catch - this transaction would be very long running. It would start when the user opened a form (I'm talking about Windows Forms here), and the commit/rollback would be when the user closed it(with OK/Cancel). So it could take anywhere between seconds and days. This requirement rules out a standard DB transaction because that would lock the tables/rows it touched, and other users wouldn't be able to use the system. Also the transaction should not commit ANY changes to the DB until it was really committed. So if one user makes some changes, others don't see them until OK button is hit. This prevents errors in case the computer crashes or is disconnected from the network.
I'm quite OK if the solution puts constraints on my model (I'm using MSSQL 2008, btw). I can design the DB/code any way I like. I'm also fine with the idea that a commit could fail because someone already modified one of the objects my transaction touched.
Is there anything like this? I looked at NHibernate.Burrow, but I'm not sure that that's the thing I want.
Added: It's the very beginning of the project so I'm not tied to NHibernate. I started out with it but I can still change easily.
As far as I can judge, DataObjects.Net supports exactly this concept via DisconnectedState. The feature is very new (released just few weeks ago), its preliminary documentation is here. WPF sample for DataObjects.Net uses it for UI transactions.
I'm not sure if it is mentioned there, but DisconnectedState, as well as its OperationLog can be serialized. So its cached state can survive even application restarts.
I don't think anyone will implement this in the NHibernate core, because nobody will use it. Viewmodel is not the same model as domain model.
This is not a direct answer to your question, but this is the sort of thing that WWF (gotta love the name) was set out to solve (not that it did so at least by v 3.5).
If you're still following this, Ayende Rahien has an article in MSDN magazine http://msdn.microsoft.com/en-us/magazine/ee819139.aspx about the session per form/presenter approach. Also take a look at chapter 5 of the NHibernate book http://manning.com/kuate/ (sample chapter available), the one on transactions and conversations.
As long as you delay the flush/transaction till the ok button is pressed, it should work (depending on the flush mode). But complete isolation is a difficult ask because your session will be able to access data that has been committed by other sessions when dealing with multiple entities. You will have to think about handling such issues.
As an aside, how would you deal with this situation if you don't use NHibernate?
EclipseLink has limited supported for such a beast. They call it "Conforming" and they implemented it in the "unit of work" context.
I've built a full-text catalog on a SQL 2005 box that, after it's re-build process completes, runs extremely slow. I've implemented a hack (i.e. try...catch{do again}) so that my users don't get a timeout error; this makes me feel bad inside. All subsequent queries are lightning fast.
Has anyone experienced this issue and was/is there a solution? Thanks!
P.S. Yes, I've Google'd it many times. Even with my left hand.
It could also be caused by this Sql Server 'feature' which we've experienced.
You may experience a 45-second delay when you run a full-text query in an instance of SQL Server 2005 that is running on a server without Internet access
http://support.microsoft.com/default.aspx/kb/915850
this might not be a direct answer to your question, but the full-text-search on mssql was covered on stackoverflow podcast series, and the conclusion was it's not the best thing :)
so, if you are able to change it to a 3rd party library, you may try what's used by jeff & co., the Apache Lucene library. Java version available at http://lucene.apache.org/java/docs/ , and .net port at http://incubator.apache.org/lucene.net/
i've had this as well. first hit very slow and rest are fast. tried all sorts and couldnt resolve it.
would love to know the answer to this one.
You could prevent having to fully rebuild the index by "setting start background updateindex" and "start change tracking" (there should be an underscore between each word) on each table that is full text indexed.
This allows sql server to update the index only with changes when required. It may help your issue since the index is not being rebuilt.
I second the Lucene.Net suggestion. I have previously tried to build a 'search engine' of sorts using Full Text Search and SQL. It was always problematic when the search criteria gets complicated and often queries would time out. On my new site I built the search engine with Lucene.Net project and it works really well and is much faster than SQL FTS.