#1 2020-03-30 20:51:09

trx
Member
Registered: 2015-08-30
Posts: 30

AV in TSQLRecord.Validate

Hi,

I occasionally get an AV from TSynValidateUniqueField.Process which is called from TSQLRecord.Validate. This happens when I have multiple threads adding/updating records.
Here is a stack trace leading up to the AV : https://pastebin.com/MaxfK1mG

The cause seems to be the use of filters in TSQLRecordProperties.Filters concurrently. More specifically, multiple threads are using and overwriting TSynValidateRest.ProcessRec:

  if wasTSynValidateRest then begin // set additional parameters
    ValidateRest.fProcessRec := self;
    ValidateRest.fProcessRest := aRest;
  end;         

Am I missing something, or should those two properties be passed to TSynValidateRest.Process as arguments instead to avoid this?

Thanks,
Svetozar Belic.

Offline

#2 2020-03-30 22:03:33

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,369
Website

Re: AV in TSQLRecord.Validate

Sounds like if this class is not thread-safe.
What if you protect its use with a lock?

Offline

#3 2020-03-31 08:31:25

trx
Member
Registered: 2015-08-30
Posts: 30

Re: AV in TSQLRecord.Validate

Hi ab,

My TSQLRecord derived class has one TID property with stored AS_UNIQUE. I don't have any other filters or validators.

The clients call a method of an interface based service IOrderApiService.Add, it is registered like so:
FApiRest.ServiceRegister(TOrderService, [TypeInfo(IOrderApiService)], sicClientDriven);

That method prepares the aggregate and then adds it to the DB via a TDDDRepositoryRestCommand descendant which is registered like this:
FMainRest.ServiceDefine(TInfraRepoOrder, [IDomOrderCommand, IDomOrderQuery], sicClientDriven);

I was under the assumption that I would not need any locks in my code if I registered the services like that.

Does this mean I have to stop using stored AS_UNIQUE and add my own thread-safe TSynValidateUniqueField-like class?

Thanks,
Svetozar Belic.

Offline

Board footer

Powered by FluxBB