Miguel, I am with you on this one ....... unless someone shows me a better
approach.......
For stuff that I *depend* on optimistic locking to support my business logic, I
wrap transactions in a *brief* osc.lock() ........ it works ..... and for
saving brain cycles I use this utility class to wrap optimistic lock
transactions:
<snip>
/**
* Deals with the nitty-gritty of a critical
<strong>short-running</strong>
* task where we depend on optimistic locking to guarantee that another
* process does not change optimistic locking attributes at the same
time. To
* understand why this is necessary, read this:
* {...@link http://terminalapp.net/dr-optimistic-locking/}.
*
* Wraps the actions in
* appropriate locks. WARNING: The OSC is locked for the period of the
* transaction. All EOF access on this OSC is blocked. Do not use this
for
* actions that take more than a few milliseconds on OSC's that are
being
* used by request threads!
*
* Code design inspired by {...@link ERXEOAccessUtilities.ChannelAction}
*
* Example of usage
*
* <pre>
* OptimisticLockAction action = new WKEOUtils.OptimisticLockAction() {
* @Override
* protected Object doPerform(EOEditingContext
actionEditingContext) {
* CTCampaign localCampaign = (CTCampaign)
actionEditingContext.faultForGlobalID(gid, actionEditingContext);
* try {
* // Ship it
* localCampaign.shipMessages();
* actionEditingContext.saveChanges();
* } catch (EOGeneralAdaptorException e) {
* String additionalInfo =
WKEOUtils.generalAdaptorExceptionInfo(e);
* log.error("Failed to ship campaign "
+ localCampaign + ". Probably another instance was sending "
* + "this
campaign to the production mail queueat the same time; AdditionalInfo: "
* +
additionalInfo, e);
* }
* return null;
* }
* };
*
* try {
* action.perform(parentObjectStore());
* } catch (Exception e) {
* throw new RuntimeException(e);
* }
* </pre>
*
* @author kieran
*/
public static abstract class OptimisticLockAction {
/**
* This method is called in a new locked editing context that
has been
* created in the osc passed in. Perform your changes in this
editing
* context. Any errors will be thrown. Return any result you
want.
*
* @param osc
*/
protected abstract Object doPerform(EOEditingContext ec);
public Object perform() throws Exception {
return perform(null);
}
/**
* @param osc
* the root object store to be locked so that true
optimistic
* locking can be enforced.
* @return the result of your doPerform method implementation
* @throws Exception
*/
public Object perform(EOObjectStore osc) throws Exception {
osc.lock();
try {
EOEditingContext ec =
WKEOUtils.newManualLockingEditingContext(osc);
ec.lock();
try {
// Don't use stale EO's to begin with
ec.setFetchTimestamp(System.currentTimeMillis());
return doPerform(ec);
} catch (Exception e) {
throw e;
} finally {
ec.unlock();
ec.dispose();
}
} catch (Exception e) {
throw e;
} finally {
osc.unlock();
}
}
}
</snip>
On May 17, 2010, at 5:33 PM, Miguel Arroz wrote:
> Hi!
>
> It's optimistic locking, and in my opinion, it's not implemented correctly
> in WO! ;)
>
> http://terminalapp.net/dr-optimistic-locking/
>
> Have fun.
>
> (I'm not sure if that blog post is 100% correct, I wrote it 2 years ago, but
> it should be enough to explain the problem)
>
> Yours
>
> Miguel Arroz
>
> On 2010/05/17, at 22:18, Theodore Petrosky wrote:
>
>> I have a small app where I create a modaldialog to edit the attributes of an
>> entity. all of the attributes are marked for 'locking' in Entity Modeler.
>>
>> I ran my app in development mode and brought up the dialog to edit the
>> attributes.
>>
>> I fired up another computer pointed the browser at the same record.
>>
>> so both computers are looking at record 1 and have different values in the
>> fields.
>>
>> I was expecting that that I could saved the changes from the browser on
>> machine one, and if I tried to save the changes from machine two the app
>> would throw an exception and I would see it in the logs....
>>
>> to my surprise, there was no error... machine two's changes were saved over
>> machine one.
>>
>> so either I am doing something wrong or I don't understand opportunistic
>> locking..
>>
>> I hope someone can help straighten me out.
>>
>> Ted
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com
>>
>> This email sent to [email protected]
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
