Connection Pool possibilities

[flamesnm]

All

Just a quick question. It's specific to my situation, but it's more a
general question on Java usage in ITDI.

I'm designing a custom ITIM adaptor that will connect to a back end
server ( an iSeries in this case ) . I'd like to make use of a
connection pool made available through JT400.jar classes.

How can I instantiate a custom class that creates the connection pool,
and have that pool of connections available when a request comes
through from ITIM ?

Thanks in advance.

[Eddie Hartman]

You may want to post this question in the Tiv Security forum as
well. I do not know TIM well enough, but I do know that not all
TDI functionality is available when using TDI to power your
RMI-based adapters. Try here:

http://ibmforums.ibm.com/forums/forum.jspa?forumID=1236

and here:

https://www.ibm.com/developerworks/forums/search.jspa?search=true&dateRange=all&q=TIM&objID=f259&x=9&y=14&rankBy=9&sortBy=0

-Eddie

[flamesnm]

Thanks Eddie. I may not have phrased the question correctly, as it
really is a TDI question. The TIM bit is incidental.

I have a Java class that defines a ConnectionPool to a backend
resource. It allows me to pre-connect to an iSeries, removing the
overhead of making the connection when a request comes in from ITIM.

Is there a way in ITDI I can instantiate a custom java class on
startup so that this connection pool can be made available to an
AL ?

[Eddie Hartman]

You have what we call "Server Hooks". These are text files
containing JavaScript code that must have specific names and
be found in a specific sub-folder of the TDI Installation. More
on this here:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_6.1.1/usersguide22.htm

So if you instantiate the class and then store a ref to it in a
Java Property:

java.lang.System.getProperties().set("pool", myPoolObj);

you can then access it from any ALs running on the same Server.

Hope this helps!
-Eddie

[flamesnm]

Bingo ! That's exactly what I was after. There's always a way with
TDI, it just needs to be prised into the open.
Thanks for your help.

[Eddie Hartman]

I prefer to think of it as "coaxing" :)

[flamesnm]

You should put that in the ITDI write up on your blog.

"ITDI. The coaxable facilitator."

[flamesnm]

Given that I'm going to be creating this connection pool to the
backend, is the best option to write a connector myself ( Script
Connector ?? ) or just to script the Create/Update/Delete
functionality as a script component and stick it in the flow section ?

Also, I'm struggling to come to terms with how RMI Server adaptors
work. Event Handlers I was clear with, but this newfangledness is
confusing.

[Eddie Hartman]

I usually do this kind of work from a series of Script components,
so I can step through with the Debugger and weed out logical
errors. The Debugger also lets you play with your Java object
interactively (instead of a gazillion logmsg()'s spread through
your code). Then once you have it all working, moving it to
a scripted Connector is easy.

Note that in TDI 7 you can also build a custom Config form for
your scripted component, making it easier to configure and
share.

As far as the details of TIM/RMI magic, I would drop this question
in one of the security forums:

http://ibmforums.ibm.com/forums/forum.jspa?forumID=1236
and:
https://www.ibm.com/developerworks/forums/search.jspa?search=true&dateRange=all&q=TIM&objID=f259&x=9&y=14&rankBy=9&sortBy=0

Note that the second link is a search, so you will need to select
a relevant post, and from there post your own question.

Hope this helps,
-Eddie

[flamesnm]

Thanks again Eddie.

[flamesnm]

> The Debugger also lets you play with your Java object > interactively (instead of a gazillion logmsg()'s spread through
> your code).

Is this function ITDI 7.0 specific ? I can't dig that information out
of the debugger in 6.1.1. I can see the Java object, but can't
interact with it.

[Eddie Hartman]

Works for both TDI 6 and TDI 7. Video on it here:
http://www.tdi-users.org/twiki/bin/view/Integrator/LearningTDI#DebuggerVideo

That is what the JavaScript command line is for - that that innocuous
text input field to the right of the Stepper button toolbar. Type in
any
snippet of script there, press ENTER and TDI sends it to the active
TDI Server (even if you are working remotely against a z mainframe)
and executes it in the context of the running AL.

dt = new java.util.Date() <ENTER>
task.logmsg(system.formatDate(dt, "YYYY-MM-dd")) <ENTER>
function log(msg) {task.logmsg(msg)} <ENTER>
ms = system.getClass().getMethods(); for (m in ms) log("-> " + m)
<ENTER>

So you can define and work with script variables and instantiate and
manipulate Java objects - just like you can from code inside an
AL. Of course, it's all one-liners which can be a bit cramped, but you
do get a history of old commands.

It may be my favorite part of TDI :)
-Eddie

[flamesnm]

Holy smokes ! That's genius ! It's going to save me hours. I really
should RTFM from time to time.

[Eddie Hartman]

No self-flagellation required :) Few know about the Debugger and
the docs have been too vague. We have tried filling the gap with
videos -- and the Getting Started Guide for TDI 7 includes it in
the tutorial exercises now -- and I am always ranting about it
here and in other fora. Slowly the news is getting out.

All I can say is: spread the word. The Debugger has been my invaluable
wingman on excursions into the wilds of rmi/jmx communications
(grabbing metrics from appserver beans and driving them to datamart),
AJAX (http server connector stuff, like REST/APP/RSS/WS) and the
Notes/Domino api. I'm one of those people who learns by touching.
The Debugger lets me do this.

End of rant,
-Eddie :)