Recursive stateless components should work just fine, I use them all
the time. In the stateless side, each time it needs an instance of
the component if there isn't an instance available to service the
need, it will create a new instance for the pool. Its possible that
1 instance will only ever be created if multiple threads don't need
an instance at the same time, its also possible to have n instances
where n is the number of threads, and in the recursion case it could
even get up to n*max recursion depth.
-Ryan
On Dec 7, 2006, at 9:29 AM, Chuck Hill wrote:
On Dec 7, 2006, at 7:49 AM, Pierre Bernard wrote:
A stateless component should be locked to one request/response
loop and thus thread at a given time. No two things should happen
concurrently.
If the stateless component is needed by another thread, a new copy
will be created.
I have had a similar problem that I traced back to having my
stateless component recursively embedded within itself. In that
case the same instance of the component does indeed get used at
two different places (within the same thread). The results of this
seem pretty unpredictable.
I cringe to think of the pain that debugging that one must have
caused!
Francis, unless your situation is the one that Pierre describes,
that is a bug. I can't confirm that I have seem this nor offer a
work around. What I would do is to look at the Lock Screamer
editing context and add some thread tracking code like that to see
if you can catch which thread is calling reset() and when. That
will at least assist in providing a bug report and may even suggest
a work around.
Chuck
On 7 Dec 2006, at 16:30, Ulrich Köster wrote:
I've hit the send button to early. The special thing about a
stateless component is that only one instance of the component is
used. With concurrent request handling it's very likely that a
reset and valueForKey are called at eh same time.
Uli
Am 07.12.2006 um 16:25 schrieb Ulrich Köster:
_flag is a state !
public boolean flag() {
Boolean _flag;
if(_flag == null) {
// Initialize _flag to a Boolean instance: it can't be set to
null
[...]
}
return _flag.booleanValue();
}
public boolean isStateless() { return true; }
public boolean synchronizesVariablesWithBindings() { return
false; }
Am 07.12.2006 um 16:12 schrieb Francis Labrie:
Hi,
I have several WebObjects 5.3.2 applications deployed in
production running with Java 5, and I've found something
worrying with stateless components. By the way, these
applications are set to allow concurrent request.
I have an heavily used stateless component managing is own
bindings synchronisation:
public class Cell extends WOComponent {
// Private instance variable
private Boolean _flag;
// Code removed for clarity...
[...]
public boolean flag() {
if(_flag == null) {
// Initialize _flag to a Boolean instance: it can't be set
to null
[...]
}
return _flag.booleanValue();
}
public boolean isStateless() { return true; }
public void reset() {
super.reset();
// The only place in the variable is set to null
_flag = null;
}
public boolean synchronizesVariablesWithBindings() { return
false; }
}
But sometimes (less than 1% of concurrent requests), I get a
NullPointerException on the "return _flag.booleanValue();"
line! And this is only an evidence of the problem: sometimes I
also get incorrect values. Normally, this can't be the case
according to the WOComponent documentation:
<< Note that a stateless component's instance variables will
remain valid for the duration of the phase
(takeValuesFromRequest , invokeAction , appendToResponse );
this lets you use instance variables in the stateless
components to hold things analogous to items in a WORepetition. >>
And IIRC, WebObjects use only one instance of a stateless
component per thread. So I must conclude another thread called
"reset()" on the same component instance, violating the
WOComponent contract quoted above. This seems to be a bug in
WebObjects... Can someone confirm this? Is their any
workaround? I've tried to syncronize the stateless component in
the appendToResponse method, but it leads to deadlocks on
concurrent requests...
Kind regards,
--
Francis Labrie
Saint-Bruno-de-Montarville, Quebec, Canada
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
ulrich.koester%40assense.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
ulrich.koester%40assense.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects-
lists%40houdah.com
This email sent to [EMAIL PROTECTED]
- - -
Houdah Software s. à r. l.
http://www.houdah.com
- Quality Mac OS X software
- Premium WebObjects consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/rklems%
40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
