Concurrency and timestamp column

Posts   
 
    
Rob
User
Posts: 54
Joined: 17-Sep-2004
# Posted on: 24-Sep-2019 08:13:54   

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?

I would appreciate a reply in the matter. If all these timestamp fields I have in all these tables are meaningless (I do not use the values) then I should remove them.

Regards

Robert Eliasson

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39568
Joined: 17-Aug-2003
# Posted on: 24-Sep-2019 14:31:50   

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 simple_smile We see your posts, we'll answer within a day, no worries wink )

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?

Frans Bouma | Lead developer LLBLGen Pro
Rob
User
Posts: 54
Joined: 17-Sep-2004
# Posted on: 24-Sep-2019 15:46:41   

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.

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? 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?

Regards

Rob

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39568
Joined: 17-Aug-2003
# Posted on: 24-Sep-2019 16:08:03   

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 simple_smile

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).

Frans Bouma | Lead developer LLBLGen Pro
Rob
User
Posts: 54
Joined: 17-Sep-2004
# Posted on: 26-Sep-2019 09:39:22   

Thanks Frans

My programmer found a solution the the timestamp issue in EF. So in the end I do not need to change my db.

As you can imagine I would not want to make any unnecessary changes to a 15 years old system that works day after day, year after year.

The fact the the column I called Concurrency using a timestamp type seems utterly pointless is something I can reluctantly live with.

Regards

Rob

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39568
Joined: 17-Aug-2003
# Posted on: 26-Sep-2019 16:53:59   

Heh simple_smile Yeah it just gets updated every time the row changes, it has no other function simple_smile Cheers!

Frans Bouma | Lead developer LLBLGen Pro