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

On 11/22/2010 11: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?

It makes sense, but really isn't germane to the point. Like most implementation details, the idea of whether you should run each connection pool in its own application server instance (as an example) as opposed to all in one larger instance depends on factors external to this discussion. Factors such as number of concurrent users might be one issue, while JVM version dependencies could be another (for example, one tenant might require a specific JVM that the others do not - this would require separate instances).

So it's an interesting question, but as the answer is "it depends" it sheds little light here.

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 way the pool works is that if it finds an available connection that matches your requirement, it returns that connection. This is the fundamental concept of a pool.

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".

Terminology gets blurred in this sort of discussion. The term "stateful" might be a better fit: a connection to the host is made when the user logs in and this connection is held throughout the length of the user's interaction with the site. In specific terms in the IBM i world, you end up with a job named QZRCSRVS in QUSRWRK which is dedicated to that specific client. The server job is not swapped amongst other jobs. It is in fact the web equivalent to your interactive job in the 5250 environment.

While not a perfect fit for all applications, where it does fit this architecture is very simple, very flexible and so very, very fast.

Joe