Client-side object modifications can now be safely merged with the database-side object state, when changed properties sets do not intercept. To enable this new mode, apply the OptimisticLocking attribute with the OptimisticLockingBehavior.LockModified parameter. New options are now available for the Session.OptimisticLockingReadBehavior property - it can now be set to MergeCollisionIgnore, MergeCollisionThrowException and MergeCollisionReload (you can also change the behavior for each persistent class individually, via the OptimisticLockingReadBehavior attribute).
Ticket
S170226
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
great - that sounds promissing!!
Great Idea for large objects!!
Finally!!!
Rethinking this, I have properties in all of my BOs (implemented in my base class) that are *always* modified, and thus there will *always* be an interception, eg. ModifiedBy and ModifiedOn.
So I would need an attribute like [MergeCollisonIgnore(true)] applicable to properties.
Any thoughts, guys?
Thank you for your feedback, Robert. I have created a new ticket for your suggestion - OptimisticLocking - Ignore collisions for specific object members.
based on the description i thought XPO will *automaticly* merge an collission during an commit? based on what i see in the example, i guess i have to manually reload the object, and the reload will do the merge - right?
Yes, merging will not be automatically performed when the optimistic locking is triggered. It is required to execute the code demonstrated in the attached example to merge changes.
I did not even try to understand the example ;-)
A XAF example would be nice.
Can this be made generic and put into a base class?
@Robert: Thank you for your feedback. We do not have a ready example for this particular scenario, but we agree that it would be valuable to perform research in this regard: Core - Support the Session.TrackPropertiesModifications option to allow resolving data collisions
See also the "Track Properties Modifications" section in the XpoTutorials demo (%Public%\Documents\DXperience 12.2 Demos\XPO\CS\XpoTutorials\ModifiedProperties).
the example provided in ReloadExample helps me to do the merge - no matter what.
But I want that when I try to do a commit with a value that has been changed in the while to throw an exception. I should never let overwrite values. Still when on first unitOfWork I change Property1 and on another unitOfWork I change Property2 the merge should be done.
But when on first unitOfWork I change Property1 and on another unitOfWork I change the same Property1 the merge should fail.
What should I change in the provided LockingHelper class in order to achieve this?
Hello Alexa,
To process your recent post more efficiently, I created a separate ticket on your behalf: T336453: Throw exception during merge when the same object properties were changed from several sessions. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.
Greetings!
related question by multi-user work …
Will there be a permanent lock when these fields change (described in the Field-Level Locking article)?
how to exclude these fields from "Field-Level Locking" validation?
Hello,
We need additional time to answer your questions.
Thanks,
Andrey
Hello,
I've created a separate ticket on your behalf (T959552: How to exclude properties from "Field-Level Locking" validation). It has been placed in our processing queue and will be answered shortly.
Thanks,
Andrey