er.extensions.concurrency

Class ERXWOLongResponsePage

java.lang.Object

com.webobjects.appserver.WOElement

com.webobjects.appserver.WOComponent

com.webobjects.woextensions.WOLongResponsePage

er.extensions.concurrency.ERXWOLongResponsePage

All Implemented Interfaces:

WOActionResults, NSKeyValueCoding, NSKeyValueCoding.ErrorHandling, NSKeyValueCodingAdditions, NSValidation, Serializable, Cloneable, Runnable

public abstract class ERXWOLongResponsePage
extends WOLongResponsePage

ERXWOLongResponsePage is just like WOLongResponsePage except that it cleans up editing context locks at the end of run() just like the behavior at the end of a normal R-R loop.

See Also:

Serialized Form

Author:

mschrag

Nested Class Summary

Nested classes/interfaces inherited from class com.webobjects.appserver.WOComponent

WOComponent._EventLoggingEnabler, WOComponent.Event

Nested classes/interfaces inherited from interface com.webobjects.foundation.NSKeyValueCodingAdditions

NSKeyValueCodingAdditions.DefaultImplementation, NSKeyValueCodingAdditions.Utility

Nested classes/interfaces inherited from interface com.webobjects.foundation.NSKeyValueCoding

NSKeyValueCoding._BooleanFieldBinding, NSKeyValueCoding._BooleanMethodBinding, NSKeyValueCoding._FieldBinding, NSKeyValueCoding._ForwardingBinding, NSKeyValueCoding._KeyBinding, NSKeyValueCoding._KeyBindingCreation, NSKeyValueCoding._MethodBinding, NSKeyValueCoding._NumberFieldBinding, NSKeyValueCoding._NumberMethodBinding, NSKeyValueCoding._ReflectionKeyBindingCreation, NSKeyValueCoding.ErrorHandling, NSKeyValueCoding.MapImplementation, NSKeyValueCoding.Null<T>, NSKeyValueCoding.UnknownKeyException, NSKeyValueCoding.ValueAccessor

Nested classes/interfaces inherited from interface com.webobjects.foundation.NSValidation

NSValidation._MethodBinding, NSValidation._ValidationBinding, NSValidation.DefaultImplementation, NSValidation.Utility, NSValidation.ValidationException

Field Summary

Fields inherited from class com.webobjects.woextensions.WOLongResponsePage

_cancelled, _done, _doneAndRefreshed, _exception, _performingAction, _refreshInterval, _result, _status

Fields inherited from class com.webobjects.appserver.WOComponent

_Extension, _IsEventLoggingEnabled, _keyAssociations

Fields inherited from interface com.webobjects.foundation.NSKeyValueCoding.ErrorHandling

_CLASS

Fields inherited from interface com.webobjects.foundation.NSKeyValueCodingAdditions

_CLASS, _KeyPathSeparatorChar, KeyPathSeparator

Fields inherited from interface com.webobjects.foundation.NSKeyValueCoding

NullValue

Fields inherited from interface com.webobjects.foundation.NSValidation

_CLASS

Constructor Summary

Constructors

Constructor and Description
ERXWOLongResponsePage(WOContext context)

Method Summary

Modifier and Type	Method and Description
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.
<T extends WOComponent> T	pageWithName(Class<T> componentClass)
<T extends WOComponent> T	pageWithName(Class<T> componentClass, WOContext context)
protected EOObjectStore	parentObjectStore() See Effective Java item #71 for explanation of this threadsafe lazy initialization technique
void	run()
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 com.webobjects.woextensions.WOLongResponsePage

_exception, _finishInitialization, _setException, appendToResponse, cancel, cancelPageForStatus, invokeAction, isCancelled, pageForException, pageForResult, performAction, refresh, refreshInterval, refreshPageForStatus, result, setCancelled, setRefreshInterval, setResult, setStatus, status

Methods inherited from class com.webobjects.appserver.WOComponent

__valueForBinding, _associationWithName, _awakeInContext, _childTemplate, _cleanUpStatelessComponent, _componentDefinition, _componentUnroll, _isPage, _setContext, _setIsPage, _setParent, _setSubcomponent, _sleepInContext, _subcomponentForElementWithID, _templateNameForClass, _unroll, application, awake, baseURL, bindingKeys, canAccessFieldsDirectly, canGetValueForBinding, canSetValueForBinding, clone, context, debugString, descriptionForResponse, ensureAwakeInContext, frameworkName, generateResponse, handleQueryWithUnboundKey, handleTakeValueForUnboundKey, hasBinding, hasSession, isCachingEnabled, isEventLoggingEnabled, isStateless, logString, name, pageWithName, parent, path, pathURL, performParentAction, pullValuesFromParent, pushValuesToParent, reset, session, set_componentUnroll, set_unroll, setCachingEnabled, setValueForBinding, setVariableValueForName, sleep, synchronizesVariablesWithBindings, takeValueForKey, takeValueForKeyPath, takeValuesFromRequest, template, templateWithHTMLString, templateWithHTMLString, templateWithHTMLString, templateWithName, toString, unableToSetNullForKey, validateTakeValueForKeyPath, validateValueForKey, validationFailedWithException, valueForBinding, valueForBooleanBinding, valueForIntegerBinding, valueForKey, valueForKeyPath, valueForNSArrayBindings, valueForNSDictionaryBindings, valueForNumberBinding, valueForStringBinding, variableValueForName, variableWithName

Methods inherited from class java.lang.Object

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

Constructor Detail

ERXWOLongResponsePage

public ERXWOLongResponsePage(WOContext context)

Method Detail

pageWithName

public <T extends WOComponent> T pageWithName(Class<T> componentClass)

pageWithName

public <T extends WOComponent> T pageWithName(Class<T> componentClass,
                                              WOContext context)

run

public void run()

Specified by:

run in interface Runnable

Overrides:

run in class WOLongResponsePage

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.