er.extensions.concurrency

Class ERXTask<T>

java.lang.Object

er.extensions.concurrency.ERXTask<T>

Type Parameters:

T - if you implement a Callable this is the result type of the callable, if you implement a Runnable you don't need to specify this.

public abstract class ERXTask<T>
extends Object

A convenience class that provides some common logic that is used in Runnable and/or Callable tasks. It provides support for cleaning up editing context locks at the end of your task's run() method just like the behavior at the end of a normal R-R loop.

Author:

kieran

Constructor Summary

Constructors

Constructor and Description
ERXTask()

Method Summary

Modifier and Type	Method and Description
T	_call() Override _call to provide your task's implementation if you have a Callable.
void	_run() Override _run to provide your task's implementation if you have a Runnable.
T	call() If you have a Callable do not override call directly.
protected EOEditingContext	newEditingContext() You must manually lock and unlock the editing context returned by this method. It is not recommended that you depend on auto locking in background threads.
protected EOObjectStore	parentObjectStore() See Effective Java item #71 for explanation of this threadsafe lazy initialization technique
void	run() If you have a Runnable do not override run directly.
void	setParentObjectStore(EOObjectStore parentObjectStore)
protected long	taskEditingContextTimestampLag() By design EOEditingContext's have a fetch timestamp (default is 1 hour) that effectively creates an in-memory caching system for EOs.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

ERXTask

public ERXTask()

Method Detail

run

public final void run()

If you have a Runnable do not override run directly. Instead, override _run. The run method in ERXTask makes your _run method appear to be in a request, and cleans up resources at the end of the request.

_run

public void _run()

Override _run to provide your task's implementation if you have a Runnable.

call

public final T call()
             throws Exception

If you have a Callable do not override call directly. Instead, override _call. The call method in ERXTask makes your _call method appear to be in a request, and cleans up resources at the end of the request.

Returns:

computed result

Throws:

Exception - if unable to compute a result

_call

public T _call()
        throws Exception

Override _call to provide your task's implementation if you have a Callable.

Returns:

computed result

Throws:

Exception - if unable to compute a result

parentObjectStore

protected final EOObjectStore parentObjectStore()

See Effective Java item #71 for explanation of this threadsafe lazy initialization technique

Returns:

the parent, usually an EOObjectStoreCoordinator to partition the task's EOF intensive work form the rest of the app.

setParentObjectStore

public final void setParentObjectStore(EOObjectStore parentObjectStore)

Parameters:

parentObjectStore - the parent, usually an EOObjectStoreCoordinator to partition the task's EOF intensive work from the rest of the app. If you are going to manually set this, you should do it before starting the task.

newEditingContext

protected EOEditingContext newEditingContext()

You must manually lock and unlock the editing context returned by this method. It is not recommended that you depend on auto locking in background threads. Even though this method currently returns an auto-locking EC if auto-locking is turned on for the app, a future update is planned that will return a manually locking EC from this method even if auto-locking is turned on for regular ECs used in normal request-response execution.

Returns:

a new EOEditingContext.

taskEditingContextTimestampLag

protected long taskEditingContextTimestampLag()

By design EOEditingContext's have a fetch timestamp (default is 1 hour) that effectively creates an in-memory caching system for EOs. This works great for users browsing through pages in the app. However, experience has shown that background EOF tasks are performing updates based on the state of other EOs, and thus we want to This is a long-running task. The last thing I want to do is perform a long running task with stale EOs, so we lazily create a fetch timestamp of the current time when we create the first EC and thus ensure fresh data. Secondly, we continue, by default to use this timestamp for the duration of the task since experience has shown that by doing so we can prevent unnecessary database fetching especially when our task is adding lots of items to a single relationship in batches. However if you want fresh data each time you create an EC in your task, feel free to set the fetch time stamp to the current time in your task each time you create a new EC. For R-R ec's we prefer fresh data on new pages. However for long running tasks, it is often best pick a single point in time, usually when the first ec is created as the timestamp lag. This works well when we are iterating and making new ec's especially if we are adding 100's of items to a relationship and cycling ec's

Returns:

the timestamp lag to use for new ec's created in the task thread.