You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Timo Hatakka <ti...@helsinki.fi> on 2013/11/18 15:35:44 UTC
Locking
Hi,
there seems to be no locking mechanism in Syncope? We have investigated REST
calls between UI and core and the idea seems to be to enumerate the
attribute level changes needed in update operation. This keeps the data
consistent if two simultaneous operations are targeted to different
attributes. In a case of multivalue attributes an updated value can be
missed if two simultaneous operations happen to the same attribute. Have you
worried about this?
Best regards,
Timo
Re: Locking
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 19/11/2013 07:33, Timo-V Hatakka wrote:
> Hi!
>
>>>
>>> there seems to be no locking mechanism in Syncope? We have
>>> investigated REST
>>> calls between UI and core and the idea seems to be to enumerate the
>>> attribute level changes needed in update operation. This keeps the data
>>> consistent if two simultaneous operations are targeted to different
>>> attributes. In a case of multivalue attributes an updated value can be
>>> missed if two simultaneous operations happen to the same attribute.
>>> Have you
>>> worried about this?
>>
>> Hi,
>> any concurrency (and locking) mechanism is delegated to the
>> underlying JPA layer, provided by OpenJPA: by default, everything is
>> configured for optimistic locking.
>> Exceptions raised at this level will be transformed into adequate
>> REST exceptions.
>
> I suppose that JPA layer does not solve the example I mentioned. You
> can verify this: open same user to two browser for update. Add two
> different values to a multivalue attribute and save. First update will
> be missed. Perhaps very rare but possible case. I tested this also
> with role memberships. The problems is not there, which is good thing.
You're correct: currently, this "rare" concurrent updates are just not
an issue: the link I've provided below, for ETag support, will improve
things in this respect.
Regards.
>> About this, there is an improvement planned for 1.2.0 about ETag
>> support:
>>
>> https://issues.apache.org/jira/browse/SYNCOPE-429
>>
>> Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Locking
Posted by Timo-V Hatakka <ti...@helsinki.fi>.
Hi!
>>
>> there seems to be no locking mechanism in Syncope? We have investigated REST
>> calls between UI and core and the idea seems to be to enumerate the
>> attribute level changes needed in update operation. This keeps the data
>> consistent if two simultaneous operations are targeted to different
>> attributes. In a case of multivalue attributes an updated value can be
>> missed if two simultaneous operations happen to the same attribute. Have you
>> worried about this?
>
> Hi,
> any concurrency (and locking) mechanism is delegated to the
> underlying JPA layer, provided by OpenJPA: by default, everything is
> configured for optimistic locking.
> Exceptions raised at this level will be transformed into adequate
> REST exceptions.
I suppose that JPA layer does not solve the example I mentioned. You
can verify this: open same user to two browser for update. Add two
different values to a multivalue attribute and save. First update will
be missed. Perhaps very rare but possible case. I tested this also
with role memberships. The problems is not there, which is good thing.
Regards,
Timo
> About this, there is an improvement planned for 1.2.0 about ETag support:
>
> https://issues.apache.org/jira/browse/SYNCOPE-429
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Re: Locking
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 18/11/2013 15:35, Timo Hatakka wrote:
> Hi,
>
> there seems to be no locking mechanism in Syncope? We have investigated REST
> calls between UI and core and the idea seems to be to enumerate the
> attribute level changes needed in update operation. This keeps the data
> consistent if two simultaneous operations are targeted to different
> attributes. In a case of multivalue attributes an updated value can be
> missed if two simultaneous operations happen to the same attribute. Have you
> worried about this?
Hi,
any concurrency (and locking) mechanism is delegated to the underlying
JPA layer, provided by OpenJPA: by default, everything is configured for
optimistic locking.
Exceptions raised at this level will be transformed into adequate REST
exceptions.
About this, there is an improvement planned for 1.2.0 about ETag support:
https://issues.apache.org/jira/browse/SYNCOPE-429
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/