LLBLGen v2.6 final build.

I have a timestamp column in all of my tables. I did this initially because I was using LINQ and it was recommended to me for checking concurrency. However, since I am using LLBLGen and since I handle concurrency issues differently (i.e I lock the record so that only one user can edit at a time), is there any other benefit for keeping this field. I ask this because I am continually getting EntityOutOfSync exceptions. I believe the cause of this is due some asynchronous methods which save entity data on a different thread and it happens just after this. Also, I have hard coded the calls to SaveEntity to always refetch to try to solve the problem, which has been unsuccessful. The only field that would ever be out of sync would be the timestamp field. To resolve this I wanted to add the following to my config file <add key="markSavedEntitiesAsFetched" value="true"> but in the post that suggests this, it specifically mentions a timestamp field as a reason not to use this.

Thanks,

Billy Jacobs

bjacobs wrote:

I have a timestamp column in all of my tables. I did this initially because I was using LINQ and it was recommended to me for checking concurrency. However, since I am using LLBLGen and since I handle concurrency issues differently (i.e I lock the record so that only one user can edit at a time), is there any other benefit for keeping this field.

Hi Billy. As a matter of fact your Timesatmp filed is perfect for concurrency control. Check this docs link to know how to implement concurrency control in LLBLGen.

bjacobs wrote:

I ask this because I am continually getting EntityOutOfSync exceptions. I believe the cause of this is due some asynchronous methods which save entity data on a different thread and it happens just after this. Also, I have hard coded the calls to SaveEntity to always refetch to try to solve the problem, which has been unsuccessful. The only field that would ever be out of sync would be the timestamp field. To resolve this I wanted to add the following to my config file <add key="markSavedEntitiesAsFetched" value="true"> but in the post that suggests this, it specifically mentions a timestamp field as a reason not to use this.

You have to check where these OurOfSync errors come from. Usually this is because you save an entity without refetching it and then you try to access its properties. markSavedEntitiesAsFetched does the trick but you really don't get the updated values after save.

This does not answer my question. I stated in my post that I am already handling concurrency issues in a different way. No 2 people are allowed to edit the record at the same time. My question is whether or not there is any benefit to keep the timestamp since I am not using it myself. Does llblgen make use of this column automatically and will it cause any problems if I remove it?

As for the EntityOutOfSync error, I am not sure what is causing this since I always pass in true to refetch. I suspect it is the result of Asyncronous Save operations I am performing. Is that a possibility?

So Questions:

1. Can I safely remove it if I am not using it for concurrency?
2. If I remove it, can I always pass in false to refetch given that I know the data in my Entity is the latest?
3. Could calling the Save operations on a separate thread cause the EntityOutOfSyncException especially if a user is moving quicker than the save operation?

Thanks,

Billy Jacobs

There is no benefits of keeping the timestamp field if you are not using it. LLBLGen Pro doesn't use it behind the scenes.

1. Can I safely remove it if I am not using it for concurrency?

Sure.

1. If I remove it, can I always pass in false to refetch given that I know the data in my Entity is the latest?

Sure.

1. Could calling the Save operations on a separate thread cause the EntityOutOfSyncException especially if a user is moving quicker than the save operation?

This one needs an explanation. The framework consider any saved entity to be out of sync. Unless it has been refetched or you have told the framework to consider it in Sync So if you are sure the entities won't be altered at the database side, then it's safe to use the config setting to mark them as in-Sync once they have been saved.

If you want to do this for some entities but not all of them, you can hardcode this in your fetch routine. myEntity.Fields.State = EntityState.Fetched