Can NHibernate somehow force a version number increment without locking the table?
I know I can do this to force a version number increment:
session.Lock(myEntity, LockMode.Force);
But the problem is that this will also aquire a physical lock on the table row, which causes big concurrency issues in my application.
In the Java Hibernate world, this seems to be possible:
session.lock(myEntity, LockMode.OPTIMISTIC_FORCE_INCREMENT);
NHibernate's LockMode.Force appears to be equivalent to Hibernate's LockMode.PESSIMISTIC_FORCE_INCREMENT, with no equivalent to LockMode.OPTIMISTIC_FORCE_INCREMENT.
Comparing the documention of the Java and .NET version, there seem to be several LockModes missing in NHibernate that exist in Hibernate.
Any ideas how to deal with that limitation?
If you use numeric version property you can just assign it to 0 and NHibernate will auto increment it for you.
Related
I'm looking over the dynamo documentation and it looks like they have optimistic. I'm wondering if this is used by default or not.
From the documentation, it looks like you need to code up the java application to use the #DynamoDBVersionAttribute annotation and get and set the versions. Without doing this, it looks like you can write to DynamoDB without any sort of locking.
Is that correct?
On a side note, I'm not too familiar with DBs without some sort of locking so what would happen if 2 people wrote to the same item at the same time in DynamoDB without any locking? Say the item we're writing to has 4 fields, would one write completely fail or is it possible that DynamoDB updates 2/4 fields with 1 write, and the other 2 fields with the other write?
You are correct. DynamoDB does NOT have optimistic locking by default. There are various SDKs for DynamoDB and as far as I am aware the only one which provides optimistic locking functionality is the Java SDK.
Here's what the Java SDK optimistic locking actually supports:
Creates an attribute in your table called version
You must load an item from the database before updating it
When you try and save an item the SDK tests that the client item version number matches the one in the table, and if it does, the save is completed and the version number is incremented
This is pretty simple to implement yourself if you are using a different SDK. You would create the version attribute yourself. You would create a wrapper for the putItem method (and any other required save/update operations). You would use the Condition Expression to test that the version number in the database is one less than the version you saving.
To answer the second part of your question, both updates would succeed (assuming you had put no conditions on your update). The first one would make any updates specified, and the second one would come along and overwrite them.
Dynamodb doesn't support optimistic locking by default. As you mentioned, you need to use the annotation in the Java model class in order to use the optimistic locking.
If two threads write to the same item, the Dynamodb item will have the last write data (i.e. last thread which writes the data).
I have been a long time user of Subsonic due to its ease of use and LINQ integration.
I now have to use something else because I need to be able to use Oracle.
I have 2 databases with the same schema therefore I want to have 1 set of POCO's and then change a connection string to switch between SQL & Oracle depending on the requirements.
Is this possible firstly, is LINQ fully functioning and stable in NHibernate and do Castle ActiveRecord and Fluent Hibernate allow the LINQ querying?
It is stable.
It is not fully functioning, and it is not planned to be fully functioning. I don't think there exists linq providers supporting 100% everything. The question should be: "Is it fully function for the queries you need to execute?" (The answer to that question would be yes in 99% of the cases)
You can find reported bugs/missing features in Jira
Fluent NHhibernate doesn't do any querying, just mapping. Castle active record doesn't query either. The linq namespace does not have a reference to active record or fluent and vise versa.
I wouldn't classify the NHibernate LINQ implementation as stable yet. The LINQ provider is still fairly young, so chance of hitting an unsupported query scneario still may be considerable in my opinion. However, other NHibernate query options are plentiful to workaround any issues the LINQ provider might throw up.
In other words, what are the main reasons to use it?
Thanks
Versioning is commonly used to implement a form of concurrency. In tables that can be accessed from different sources at the same time, a column named version is used. Nhibernate notes down the version of an object when it reads it, and when it tries to update it, it first checks that the version hasn't changed. On updating a row, the version column is incremented.
As I understand it NHibernate has a build in support for timestamps. However, it appears you can only instruct NHibernate to never update the property or always update it.
In the project I am currently working on there are several tables which have both "created_time" and "updated_time", both are to be generated by the database.
I can't figure out how to instruct NHibernate to use "getdate()" for both properties nut only on insert for "created_time" and on insert and update for "updated_time".
Is this possible?
PS: I am working with a legacy database and I am not allowed to change it, so triggers etc. are not possible solutions.
You could work around this by creating an Interceptor that sets those values, but offcourse, then those values are not generated by the DBMS offcourse ...
It might be a workaround, as I also don't know how to make sure that the DB populates those values, but I'm also interested in another solution for this issue. :)
Which version of NHibernate are you using?
In 2.0, the "generated" tag on a property has three valid values:
never (self-explanatory)
insert(will retrieve the generated value only on inserts)
always (always retrieves generated value).
How do you support optimistic / pessimistic concurrency using NHibernate?
NHibernate supports 2 types of optimistic concurrency.
You can either have it check dirty fields by using "optimistic-lock=dirty" attribute on the "class" element in your mapping files or you can use "optimistic-lock=version" (which is also the default). If you are using version you need to provide a "version" element in your mapping file that maps to a field in your database.
Version can be of type Int64, Int32, Int16, Ticks, Timestamp, or TimeSpan and are automatically incremented on save. See Chapter 5 in the NHibernate documentation for more info.
NHibernate, by default, supports optimistic concurrency. Pessimistic concurrency, on the other hand, can be accomplished through the ISession.Lock() method.
These issues are discussed in detail in this document.
You can also 'just' manually compare the version numbers (assuming you've added a Version property to your entity).
Clearly Optimistic is the only sane option. Sometimes of course, we have to deal with crazy scenarios however...