Sorry. I missed that the fields to be locked change for each commit.
Michael is right in that you'd need to copy the DataMap for each one
so that the current commit doesn't affect another commit. Either
that, or you'd have to insure some other form of synchronization for
the code doing the "set fields to lock/commit/reset fields".
You could not vary the locking on a specific entity within a specific
commit, but that's probably not a problem for your situation.
I did write the original optimistic locking code with Andrus' help,
but that was back for Cayenne 1.1. The differences tracking has been
completely rewritten since then, so I'm probably not going to be of
much help.
The most portable way to do it would be to copy the DataMap before
each commit, and make the changes if Michael has a way to do that.
I'm sure there's a way to detect which fields have changed from user
code, but I don't know it off hand. I think I have some audit logging
code for Cayenne 1.2 that probably does this. I can look for it if
you want to go this route.
Or if performance isn't a huge issue, you can synchronize on something
global, manually change the locking, and reset it back after the
commit, and release the lock.
The third option would be to patch the cayenne core and submit the
changes back for review and incorporation. You'd want to get a lot
of comment on the dev list if you go that route.
On Tue, Nov 25, 2008 at 1:50 PM, BL <bleu..mx.de> wrote:
> On Tue, 25 Nov 2008 11:37:58 -0500 "Mike Kienenberger" <mkienen..mail.com> wrote:
>
>> I still think it's already possible to do what you want.
>>
>> Please give me a concrete example of what you're trying to do, and
>> I'll help you see how to do it.
>
> Let me try it with some pseudo statements for one table:
>
> U1) update test set f1 = $new_val1 where pkey = $P1
> U2) update test set f2 = $new_val2 where pkey = $P2
> U3) update test set f3 = $new_val3, f4 = $new_val4 where pkey = $P3
>
> Locking qualifier:
> L1) where ... and f1 = $old_val1
> L2) where ... and f2 = $old_val2
> L3) where ... and f3 = $old_val3 and f4 = $old_val4
>
> f1, f2, f3 and f4 are all possible locking fields, but they are only used as qualifier if the field value has changed.
>
> Different clients are allowed to do any of the above changes in any combination. Sometimes a client may use U1 and U3 in one transaction, sometimes U1 and U2...
>
> Locking exceptions should only occur if a client has outdated values of fields it is trying to change.
>
> Thanks for your help.
>
>
>>> On Mon, 24 Nov 2008 18:23:51 -0500 "Mike Kienenberger" <mkienen..mail.com> wrote:
>>>>
>>>> Can't you do this already?
>>>>
>>>> Each field can be set to be optimistically-locked or unlocked individually.
>>>>
>>>> It might require manually changing your map entity definition in the
>>>> run-time if this behavior isn't constant, but that doesn't seem like a
>>>> big deal.
>>>
>>> Not only at runtime, it changes within the active sync process.
>>>
>>> Just to be sure: DataNodeSyncQualifierDescriptor.reset seems to call attribute.isUsedForLocking to detect attributes it has to add to the qualifier (I think you wrote this part)?.
>>>
>>> Is it possible to influence this process from outside - without knowledge of the ObjectDiff - while the query appending happens? This would be great, but I don't see it. Do you have a hint for me?
>>>
>>> BTW: What's the best practice to implement this without getting problems in the next Cayenne release?
>>>
>>>> On Fri, Nov 21, 2008 at 9:54 AM, BL <bleu..mx.de> wrote:
>>>>> the idea is to have a table related setting to request optimistic
>>>>> locking for the changed properties only. This would allow shared write
>>>>> access for clients using a distinct set of fields.
>>>>>
>>>>> Without global support a customized UpdateBatchQueryBuilder could
>>>>> do it probably locally, only access to the snapshot (getChangesByObjectId)
>>>>> of the current entity would be required.
>>>>>
>>>>> Is there any interest in such a feature?
> --
> Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL
> für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
>
This archive was generated by hypermail 2.0.0 : Tue Nov 25 2008 - 14:07:32 EST