Concurrency and timestamp column
Joined: 17-Sep-2004
Rob wrote:
Hi guys
It has now been 14 years or so when I first started my project on LLBLGen Pro.
Back then, from memory, your documentation recommended that I would add a column to each table, call it Concurrency and give it the timestamp type.
My memory is very vague about this recommendation but I have kept this Concurrency column by type timestamp in many of my tables over the years.
An external programmer writing something for me right now is using EF and he is getting issues from the Concurrency column (ironically concurrency issues).
So I thought I should ask.
Does LLBLGen use the column Concurrency of type timestamp if it exists? Or, has that been removed over the years? Or... did it never and I misunderstood back then?
(Rob, please don't email us as well, if you posted here 
We see your posts, we'll answer within a day, no worries 
)
Our framework uses a concurrency factory, which you can define and which is used to automatically produce predicates of your choosing and which thus can check whatever field or fields you want. See: https://www.llblgen.com/Documentation/5.6/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/Adapter/gencode_usingentityclasses_concurrency.htm
We don't say you should add a timestamp column, but it's a generic way to do this, as a timestamp column is updated if the row is updated (so no update to any field -> timestamp field isn't updated either), so if the timestamp value in the entity being updated is the same as in the row (which you can do with a predicate), you proceed (so the predicate should resolve to true in that case) or in the case of when they differ the predicate should result in false so the update fails and the transaction will roll back with a concurrency exception.
To be honest I don't know what EF does, also you don't specify what errors you got, so I can't go into that specifically. If you use our designer, you can use it to mark a field for concurrencycontrol, see: https://www.llblgen.com/Documentation/5.6/Entity%20Framework/V56/AvailableOutputSettings.htm#field-settings-value-type-definition-field-entity-definition-field
You can mark multiple fields at once using: https://www.llblgen.com/Documentation/5.6/Designer/Functionality%20Reference/BulkOutputSettingValuesManipulator.htm
If a field is marked for concurrency in EF it's treated like that and isn't updated by EF when you save a row. I think that's the issue you run into?
Joined: 17-Sep-2004
Rob wrote:
Hi Frans
The link you sent to your doco seems to relate to Adapter. I use Self-servicing. I also have never done anything LLBLGen related intentionally to support concurrency.
Selfservicing is here: https://www.llblgen.com/Documentation/5.6/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/SelfServicing/gencode_usingentityclasses_concurrency.htm
Just type 'concurrency' in the search box and you'll arrive there quickly
Does that mean that I can safely assume that the LLBLGen generated code will keep working the same if I remove the Concurrency columns I have added?
If you don't use the concurrencyfactory, then yes it'll work as before as nothing will really change: there's no check on the timestamp column.
I will obviously regen the stuff in your designer so that the generated code is aware that the columns are gone. I myself never make any reference at all to these concurrency timestamp columns and if LLBLGen (Self-servicing) doesn't either then I could just get rid of them presumably.
Would that be correct?
Yes.
If you want to have the concurrency feature later on, you can add them to tables where it makes sense (e.g. where you expect multiple users/threads editing the same row/entity).
Joined: 17-Sep-2004
Heh Yeah it just gets updated every time the row changes, it has no other function Cheers!