• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Antw: Re: EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT'
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Antw: Re: EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT'


  • Subject: Re: Antw: Re: EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT'
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 6 Nov 2008 09:42:26 -0800

Please keep responses on the list.


On Nov 5, 2008, at 5:52 AM, Andri vonAllmen wrote:

Hi Chuck,

thanks for your response.

Why pessimistic locking? In this case it would be used for a task scheduler (for executing stored procedures, static methods, etc.).

Some explanation:

The application is running on multiple instances, which all use the same database.
The scheduled jobs are stored in the database (interval [min] / / daily (time, day(s)) / weekly (time, day) / monthly (time, day of month or on last day of month), etc.).
A timer in the application is looking for outstanding jobs in a certain interval by querying the database. Only those jobs scheduled to be executed at the time the database query is made (with some hysteresis), are queried, and the query itself ought to lock them (pessimistic). Pessimistic, because no other instance may query these records at the same time (method setLocksObjects() provides this functionality with the lack of the 'NOWAIT' appendix). The 'NOWAIT' behaviour is needed, because locked records (in this case) do imply them to be due to be executed at this time. Waiting for them to be unlocked, would cause into a rescheduling and even in multiple execution.


You may think, that it would be a good idea to implement and set a 'isRunning' flag on each job (in the database) directly after fetching it. But in this case, the time between selecting the record and setting the 'isRunning' flag is arbitrative, and this span will suffice that other instances execute the same job at the same time (the chance, that this happens is not too big, but it's possible). A trigger for triggering for SELECT queries does not exist (just befre or after update, delete..)

As i thought about how to implement such a task scheduler i arrived at the conclusion that it would be the easiest to use the 'SELECT FOR UPDATE NOWAIT' behaviour, and the 'NOWAIT' part is where i stuck.

Now, i will manupilate the SQL that has to be generated somwhere..sometime...before fetching is made, by simply appending the 'NOWAIT' appendix.

You need a better plan, not NOWAIT. Rather than have multiple instances all doing this, create an application (or configure an instance) specifically for this task. Then you have no race condition. If one app won't handle it, then partition the types of jobs that each fetches so that each type is fetched by only one instance.


If you really think you need multiple instances all going at the data at the same time, then yes, add a isRunning flag, but use it like this:

1. Fetch jobs
2. For each job:
	2a. Set isRunning flag
	2b. Save job
	2c. If save does NOT throw an OptimisiticLockingException, start job

The job ONLY gets start if this instance is successful in saving the change to the isRunningFlag.

Chuck


>>> Chuck Hill <email@hidden> Dienstag, 4. November 2008 19:57 >>>

On Nov 4, 2008, at 1:41 AM, Andri vonAllmen wrote:

> Hi,
>
> a EOFetchSpecification that locks objects and throws an exception on
> any other access trials (SELECT, UPDATE, whatever) is required.


Why? This sounds like Pessimistic Locking. EOF is really intended to be used with Optimistic Locking. What will happen if you make these locks and the user closes their browser? You can set EOF to use Pessimistic Locking, but I don't think anyone uses this and you are likely to find a lot of bugs.


> The behaviour should be the same as the SQL Statement 'SELECT FOR > UPDATE NO WAIT'. > > For locking objects ('SELECT FOR UPDATE') the EOFetchSpecifications > method 'setRefreshesRefetchedObjects' is used: > > EOFetchSpecification spec = new EOFetchSpecification("AnEntity", > qualifier, null); > spec.setRefreshesRefetchedObjects(true); > > For the 'NO WAIT' clause, the OracleSQLExpressions > 'setUseNoWaitLocks' method seems to be the right one, but i could > not figure out, how to apply it (i'm new to java...and english > speaking -.-).

That class and method are very low level, getting down there is not
going to be easy.


> Any helpful hints or examples how to use 'setUseNoWaitLocks' would > be appreciated.

I'd try to find a different way to implement your requirements.

Chuck


-- Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects







-- Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects







_______________________________________________ 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
References: 
 >EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT' (From: "Andri vonAllmen" <email@hidden>)
 >Re: EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT' (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Update & Delete of an Enterprise Object causes EOEditingContext.saveChanges() to Exception
  • Next by Date: Re: Lots of EOs slow down the performance
  • Previous by thread: Re: EOFetchSpecification that locks objects like 'SELECT FOR UPDATE NO WAIT'
  • Next by thread: WOLips New Hotness and ant build says: woframework doesn't support the "frameworksBaseURL" attribute
  • Index(es):
    • Date
    • Thread