At first it feel strange, because my context is independant of the
thread executing the code, I don't see a relationship between the
thread running the code and the business context itself. Just that
one will be bound by the other. I would say it's a nice side effects
to be able to do it that way, but I don't see it fit natively.
The only common denominator for all my EO is really the editing
context that they share, not the thread they are in.
- jfv
Le 07-04-05 à 12:49, Chuck Hill a écrit :
On Apr 5, 2007, at 5:58 AM, Jean-François Veillette wrote:
Thanks Mike, I have a better picture now of what/where/how
ERXThreadStorage is helping.
I still think that I don't want per thread storage, we already
have request.userInfo for that and I use it only for web/request
related informations (used at the interface layer only).
I still feel uncomfortable with this concept, but I might give it
a try, I might feel better with this design once I use it in a
real project.
At the business layer (outside of a wo / rrl context) the concept
of thread doesn't hold as much (unless it's part of your business).
I don't see why that is true. We are talking about
java.lang.Thread, no WOWorkerThread. A java.lang.Thread is the
context of execution of Java code. It is the context of execution
that is relevant here.
Chuck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
