Hi,
There is discussion in our development team about what OpenEdge 11 appserver does, when an invocation comes in from a user for a different tenant than the previous invocation.
Some believe that values of variables in persistent procedures (and initialized objects) automatically switch in a stateless/statefree appserver.
So, if user Bob (who is member of tenant "ACME") sets variable Companyname="ACME" in a persistent proc, then user Mary (who is member of tenant "UmbrellaCorporation") envokes that procedure and notices that Companyname is not yet assigned, then Bob comes back and sees that Companyname has value "ACME" again. Without any ABL statements that do the switch!
I refuse to believe that the above scenario is how it really works. It shouldn't work, it is a horrible scenario in my opinion. But some people insist that that is exacty how it works with multi-tenancy.
In the past there have been talks about proposed ABL syntax like: DEFINE VARIABLE CONTEXT-TENANT TEMP-TABLE ttPriceList. And I have also seen a variation: DEFINE CONTEXT-TABLE ttPriceList FOR "TENANT".
I believe that none of these proposals made it in the OpenEdge 11.0 release. Am I correct?
I do believe that ABL could transparently swap memory space for variables, or swap widget-pool pointers, but I trust they wouldn't do that without documenting it, because it is a huge change and would create as many new bugs as it would solve.
Can someone please help and tell how it works now, and what is planned?
Thanks, Jurjen.
jdijkstra schrieb:
Hi,
There is discussion in our development team about what OpenEdge 11 appserver does, when an invocation comes in from a user for a different tenant than the previous invocation.
Some believe that values of variables in persistent procedures (and initialized objects) automatically switch in a stateless/statefree appserver.
So, if user Bob (who is member of tenant "ACME") sets variable Companyname="ACME" in a persistent proc, then user Mary (who is member of tenant "UmbrellaCorporation") envokes that procedure and notices that Companyname is not yet assigned, then Bob comes back and sees that Companyname has value "ACME" again. Without any ABL statements that do the switch!
I refuse to believe that the above scenario is how it really works.
I think you're right here. Never heard of multi-tenant variables or multi-tenant persistent procedures. Only multi-tenant (DB) tables so far.
It shouldn't work, it is a horrible scenario in my opinion.
I'm not expecting it to work either - however it might be a nice option for SOME variables, but then with an additional keyword on the DEFINE VARIABLE statement, but that is not there in 11.0 either.
In the past there have been talks about proposed ABL syntax like: DEFINE VARIABLE CONTEXT-TENANT TEMP-TABLE ttPriceList. And I have also seen a variation: DEFINE CONTEXT-TABLE ttPriceList FOR "TENANT".
I believe that none of these proposals made it in the OpenEdge 11.0 release. Am I correct?
No, AFAIK that's not in 11.0 but may make it into a future release.
In a MT environment, when the current tenant ID changes, the AVM invalidates all extant db buffers, however as far as I can recall all variables and TT are left as they are. This means you don't want to persist any tenant-specific information across AS calls.
Thanks Tim, your remark about db buffers is a smart one. I did not think of that.
We have had some discussions about something called a context cache that is envisioned to have tenant and user specific parts. The point is to make it easier to develop code that can run in stateless mode appservers. But that context cache thing has not been designed and is not implemented in 11.0. At this moment there are no detailed plans for it.
gus wrote:
We have had some discussions about something called a context cache that is envisioned to have tenant and user specific parts. .... At this moment there are no detailed plans for it.
I thought you had something designed, but there wasn't enough resources to get it into 11.0, so it was pushed back to 11.1.
Not true?
We did not complete the design work when it became clear that there was no
way we could get the feature into 11.0. This is not the only thing we left
out.
This is not the only thing we left out.
Someone has to ask.... what else was left out
mikefe wrote:
Someone has to ask.... what else was left out
I recall something about a SilverLight Adapter....
if I can guess an answer it would be a PAM, Pluggable Authentication Module, for Ldap auth. Because I heard John Sadd mention the PAMs that are not available yet, in his video about Identity Management for multi-tenancy.
Actually, PAM support is partly there. The piece that is missing is the one where the plugin is written in the 4GL. The intent is that your 4GL code then validates user identity in whatever manner suits. For example, you have your own user authentication scheme built into the application, maybe using your own replacement for _user. When that plugin mechanism is available, then you will be able to create a client-principal, fill in the values for the various attributes, and then when it is validated, your 4GL module gets invoked to say yes or no.
Yes, Silverlight. We always have a long list of stuff we want to do. It happens in every release that we never get everything we wanted.
cool, I think I can write ABL code that says yes or no :-) but I am confused.... what calls it, when, with which parameters?
When that plugin mechanism is available, then you will be able to create a client-principal, fill in the values for the various attributes, and then when it is validated, your 4GL module gets invoked to say yes or no.
Probably for ABL clients only and not integrated with SQL92 clients. Right?