Re: IBM i in the cloud (was social media)

Nathan,

This is pretty much what Ali did with the Connection Manager in Ascent. If you recall, the thing we needed to solve was that AEE basically allowed for the user to chose the role they wanted to work in and that role consisted of a fiscal year (PF member) and a library list. For AEE you pretty much handled it the traditional IBM i way since your web server was in RPG but when it came to Java, we had to work with JDBC connections and that meant a wrapper using the connection manager and pooling.

Each role pointed to a different connection in the pool (I think we used role id) so as new users selected new roles (PF member/library list combinations) those connections were added to the pool. If a connection already existed for that role and was already in the pool, we used that. If not, we created a new connection and placed it in the pool. The result was multiple connections in the pool all of them having different member overrides and different library lists. The java code was just a wrapper (DBManager.jar) that managed all the oddities.

Pete Helgren
Value Added Software, Inc
www.asaap.com
www.opensource4i.com


On 11/22/2010 10:23 PM, Nathan Andelin wrote:

From: Joe Pluta
It's getting late and I must be getting confused, because AFAIK a
connection pool only returns a connection which matches the parameters
you are requesting. Those parameters typically include user ID,
password, and the connection URL, which in turn contains the connection
properties. The properties can be used to set up, for example, the
default schema. So in this case a connection would by definition only
return a connection for the correct tenant.

Thanks for that explanation. I just wanted to also explore the idea of writing
one's own connection pool manager rather than using one that might be built into
a web application server; where one of the parameters passed would be "tenant",
so that a tenant specific connection would be returned to the requester/servlet.
A library list may be defined at the time a connection is established, then
reused for subsequent requests, thereafter. Say you store tenant ID in a
session variable and use it to request a tenant specific connect from your pool
manager, thereafter. My next question is what scope should your connection pool
manager run under. Does that make sense?

The work on your part is to identify the correct connection
string for each tenant.

I understand how that could work for creating a new connection, but would it
work for requesting subsequent connections from the pool, where the pool manager
uses "tenant" to find an available connection?

The premise also cuts off some plausible alternatives. There absolutely
is no one-size-fits-all strategy.

That would be interesting to explore.

For example, persistent connections don't need any of this.
The connection sets its library list at the time it is created
and you use unqualified table names and system naming.

I thought *ALL connections in a pool were persistent; not necessarily persistent
for a specific user, but persistent nevertheless. My understanding is limited
about how connection pools are managed. I'm under the impression that in most
cases a connection is established for a server, but not necessarily for a
specific "tenant", or "user".

-Nathan