Re: ?? about opportunistic locking...
Re: ?? about opportunistic locking...
- Subject: Re: ?? about opportunistic locking...
- From: Kieran Kelleher <email@hidden>
- Date: Mon, 17 May 2010 22:21:42 -0400
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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden