Roman Rokytskyy wrote:

>>Here, I don't see why you would even think of thread locals. You
>>have some method that may need a resource, why not just give it the
>>resource to start with rather than forcing it to look it up? Even
>>EJB 3 is moving towards some dependency injection/IOC concepts.
>>
>>
>
>Yes, this is also possible. I personally am ok with TLS, but passing
>an additional parameter to do callbacks is also possible. However this
>would require us to talk about the callback mechanism too, which I
>wanted to avoid. Seems that this is not possible, so a proposal for a
>callback mechanism is needed, and it should be Vulcan-compatible to
>get Jim into discussion.
>
>
>

Sorry, but Mr. Jencks was doing such a fine job I saw no need to step in.

One of the principle tenants of structure programming is that
communication through global variables is a bad practice and must be
avoided if at all possible. The reason is straightforward -- a function
should operate strictly on the parameters passed to. A corollary is
that communicating through side effects is a dangerous practice.

Thread variables are little more than global variables -- with all the
problems of global variables -- but expensive to access to boot. Once
in a blue moon they're necessary, but the more typical usage is to pass
information to a called function that you neglected to pass through the
calling sequence. In short, a band aid.

Your code sequence:

InitialContext ctx = new InitialContext();
UserTransaction tx = ctx.lookup("UserTransaction");


is a good example of a poor use of globals. The class InitialContext
has no intrinsic context, and must grub around through globals or native
functions to find things. It would be much better for the
infrastructure to to pass the user transaction to your function than to
expect to be able to pick it out of the ether. Even better would be to
pass a full database context to your function, and in Java, the database
context is an instance of the Connection interface.

To be completely frank, I don't like the practice of pulling context out
of the ether. Every function, procedure, and method in the system
should be passed the context necessary to perform its function. There
are exceptions, like the threading package itself and the code that
manages locales and system properties. Passing database context to a
database procedure, however, should be explicit.

A secondary advantage of passing explicit database context is that it
allows a database procedure to executed in other contexts outside the
database engine. You will probably discover that debugging Java running
inside database engine is not always simple to debug. If you design
your interfaces correctly, you should be able to run a database
procedure faithfully in an external testbed.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376