Mr. Kagel:

Keep in mind, I'm not a programmer, but a DBA that writes stuff for the customer.

I was always taught to minimize globals, especially in C variants, but in general, everything.

Why does INFORMIX globals? Maybe its a philosophical thing.

Rob Konikoff

________________________________

From: informix-list-bounces@iiug.org on behalf of Art S. Kagel
Sent: Thu 1/26/2006 6:25 PM
To: informix-list@iiug.org
Subject: Another IDS Feature Request



Several days ago I proposed the following as part of a reply. I got no
comments on it. Did everyone miss it? Or is it just dumb?

Explicit globally accessible cursors. It would make writing middleware and
WEB services with context so much easier if there were a concept of a
globally accessible cursor. I implemented something like that here, but
full implementation required us to complete the query and drain the cursor
into a shared cache in order to fulfill the 'next/previous N rows' requests.
We cannot use dedicated connections, our application servers are forbidden
to connect directly to the database for many reasons I won't go into.
Further, a user's followup requests may come from a different copy of the
application server (indeed it may come from a different machine on the net)
and be handled by a different copy of the middleware server, similar to a
WEB server environment. A shift to a multi-threaded middleware model would
help somewhat, but historical global data accesses make multi-threaded
applications particularly difficult around here and not significantly more
efficient than multi-tasking ones.

So, here's a proposed syntax:

DECLARE :cursor_id_var CURSOR FOR ....;
OPEN :cursor_id_var USING .... ASSIGN GLOBAL CURSOR TO :global_id_var;

FETCH :global_id_var INTO ...;

Essentially the new ASSIGN GLOBAL CURSOR clause would prompt IDS to create a
globally accessible cursor structure and return the equivalent of a cookie
that can be used to access it later instead of or in addition to the local
cursor id.

At this point I can place global_id_var into shared memory where any copy of
the middleware server can access it. To prevent multiple connections from
accessing a global cursor simultaneously we use the shared connection model.
The connection which currently owns the global cursor relinquishes it with:

RELEASE :global_id_var;

To gain access to a global cursor a connection would:

ACQUIRE :global_id_var;

Closing either the global cursor in some connection, or the underlying
cursor in the originating connection would deallocate the global cursor and
the underlying cursor.

Anyone else like this one?

Art S. Kagel
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list

Konikoff, Rob (Contractor) wrote:
> Mr. Kagel:
>
> Keep in mind, I'm not a programmer, but a DBA that writes stuff for the
> customer.
>
> I was always taught to minimize globals, especially in C variants, but
> in general, everything.


Rob,

First, it's Art, please. Noone even calls my dad Mr. Kagel (he's "Chief" -
long story). Besides there are very few folk on CDI I wouldn't want using
my given name - maybe Mikey and Tim, but I make allowances there too. ;-)

Yeah, I abhor global variables and other uncontrolled data sharing myself.

Sometimes such constructs are the only reasonable way to solve a problem.
I hate and avoid GOTOs in source code also, and they can always be
eliminated, but sometimes the extra coding and added confusion and
maintenance overhead are just not worth the effort and a well controlled
GOTO is the more elegant and efficient solution.

This is one of those cases. Besides, I'm not talking about uncontrolled
data sharing. The global cursor id would have to be 'owned' by only one
session at a time. Perhaps calling it a 'shared cursor' would be a better
moniker.

Art S. Kagel

> Why does INFORMIX globals? Maybe its a philosophical thing.
>
> Rob Konikoff
>
> ------------------------------------------------------------------------
> *From:* informix-list-bounces@iiug.org on behalf of Art S. Kagel
> *Sent:* Thu 1/26/2006 6:25 PM
> *To:* informix-list@iiug.org
> *Subject:* Another IDS Feature Request
>
> Several days ago I proposed the following as part of a reply. I got no
> comments on it. Did everyone miss it? Or is it just dumb?
>
> Explicit globally accessible cursors. It would make writing middleware and
> WEB services with context so much easier if there were a concept of a
> globally accessible cursor. I implemented something like that here, but
> full implementation required us to complete the query and drain the cursor
> into a shared cache in order to fulfill the 'next/previous N rows' requests.
> We cannot use dedicated connections, our application servers are forbidden
> to connect directly to the database for many reasons I won't go into.
> Further, a user's followup requests may come from a different copy of the
> application server (indeed it may come from a different machine on the net)
> and be handled by a different copy of the middleware server, similar to a
> WEB server environment. A shift to a multi-threaded middleware model would
> help somewhat, but historical global data accesses make multi-threaded
> applications particularly difficult around here and not significantly more
> efficient than multi-tasking ones.
>
> So, here's a proposed syntax:
>
> DECLARE :cursor_id_var CURSOR FOR ....;
> OPEN :cursor_id_var USING .... ASSIGN GLOBAL CURSOR TO :global_id_var;
>
> FETCH :global_id_var INTO ...;
>
> Essentially the new ASSIGN GLOBAL CURSOR clause would prompt IDS to create a
> globally accessible cursor structure and return the equivalent of a cookie
> that can be used to access it later instead of or in addition to the local
> cursor id.
>
> At this point I can place global_id_var into shared memory where any copy of
> the middleware server can access it. To prevent multiple connections from
> accessing a global cursor simultaneously we use the shared connection model.
> The connection which currently owns the global cursor relinquishes it
> with:
>
> RELEASE :global_id_var;
>
> To gain access to a global cursor a connection would:
>
> ACQUIRE :global_id_var;
>
> Closing either the global cursor in some connection, or the underlying
> cursor in the originating connection would deallocate the global cursor and
> the underlying cursor.
>
> Anyone else like this one?
>
> Art S. Kagel
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>

Konikoff, Rob (Contractor) wrote:
> Mr. Kagel:
>
> Keep in mind, I'm not a programmer, but a DBA that writes stuff for the
> customer.
>
> I was always taught to minimize globals, especially in C variants, but
> in general, everything.


Rob,

First, it's Art, please. Noone even calls my dad Mr. Kagel (he's "Chief" -
long story). Besides there are very few folk on CDI I wouldn't want using
my given name - maybe Mikey and Tim, but I make allowances there too. ;-)

Yeah, I abhor global variables and other uncontrolled data sharing myself.

Sometimes such constructs are the only reasonable way to solve a problem.
I hate and avoid GOTOs in source code also, and they can always be
eliminated, but sometimes the extra coding and added confusion and
maintenance overhead are just not worth the effort and a well controlled
GOTO is the more elegant and efficient solution.

This is one of those cases. Besides, I'm not talking about uncontrolled
data sharing. The global cursor id would have to be 'owned' by only one
session at a time. Perhaps calling it a 'shared cursor' would be a better
moniker.

Art S. Kagel

> Why does INFORMIX globals? Maybe its a philosophical thing.
>
> Rob Konikoff
>
> ------------------------------------------------------------------------
> *From:* informix-list-bounces@iiug.org on behalf of Art S. Kagel
> *Sent:* Thu 1/26/2006 6:25 PM
> *To:* informix-list@iiug.org
> *Subject:* Another IDS Feature Request
>
> Several days ago I proposed the following as part of a reply. I got no
> comments on it. Did everyone miss it? Or is it just dumb?
>
> Explicit globally accessible cursors. It would make writing middleware and
> WEB services with context so much easier if there were a concept of a
> globally accessible cursor. I implemented something like that here, but
> full implementation required us to complete the query and drain the cursor
> into a shared cache in order to fulfill the 'next/previous N rows' requests.
> We cannot use dedicated connections, our application servers are forbidden
> to connect directly to the database for many reasons I won't go into.
> Further, a user's followup requests may come from a different copy of the
> application server (indeed it may come from a different machine on the net)
> and be handled by a different copy of the middleware server, similar to a
> WEB server environment. A shift to a multi-threaded middleware model would
> help somewhat, but historical global data accesses make multi-threaded
> applications particularly difficult around here and not significantly more
> efficient than multi-tasking ones.
>
> So, here's a proposed syntax:
>
> DECLARE :cursor_id_var CURSOR FOR ....;
> OPEN :cursor_id_var USING .... ASSIGN GLOBAL CURSOR TO :global_id_var;
>
> FETCH :global_id_var INTO ...;
>
> Essentially the new ASSIGN GLOBAL CURSOR clause would prompt IDS to create a
> globally accessible cursor structure and return the equivalent of a cookie
> that can be used to access it later instead of or in addition to the local
> cursor id.
>
> At this point I can place global_id_var into shared memory where any copy of
> the middleware server can access it. To prevent multiple connections from
> accessing a global cursor simultaneously we use the shared connection model.
> The connection which currently owns the global cursor relinquishes it
> with:
>
> RELEASE :global_id_var;
>
> To gain access to a global cursor a connection would:
>
> ACQUIRE :global_id_var;
>
> Closing either the global cursor in some connection, or the underlying
> cursor in the originating connection would deallocate the global cursor and
> the underlying cursor.
>
> Anyone else like this one?
>
> Art S. Kagel
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>

Michael Segel wrote:
> Art S. Kagel wrote:
> Gee Mr. Kagel, such a mensch.

Ahh, shucks Mikey. 8-P

> BTW, if you have to use a GOTO and I don't mean JSR in assembler, your
> solution is neither elegant nor worth repeating. ;-)

There's nothing elegant about having to test a condition variable at each
level of a deeply nested logic structure to exit the block on an error
condition. I think that it is more elegant to 'goto error_exit;' instead.
Do I do that to shortcut out of a single block? No! And I'll go so far as
to scratch my wrist with my belt loops, but I'm not twisting my code to
scratch my ear on my shoelace.

> Yes, you should minimize your use of globals, but that doesn't mean don't
> use globals when they make sense.

Agreed. I DO use globals when it makes sense, I just think twice about it
and normally leave myself a comment like /* GLOBALS - I hate these things.
*/ as a reminder to keep them from getting out of hand later.

> But hey, what do I know?
> I believe that a little Mishigas never hurt anyone.

I won't argue.

Art S. Kagel

> <SNIP>

Michael Segel wrote:
>> BTW, if you have to use a GOTO and I don't mean JSR in assembler, your
>> solution is neither elegant nor worth repeating. ;-)

Technically, (Read as, I am just trying to stir up trouble ;-) ) JSR is
not a goto in assembler but a GOSUB because it pushes the address of
the next instruction after the JSR on the stack before it jumps so that
a RET can pop it off of the stack at the end of the routine to start
executing where the JSR had left off.

"bozon" <curtis@crowson1.com> wrote in message
news:1138720786.210494.138470@g47g2000cwa.googlegr oups.com...
> Michael Segel wrote:
> >> BTW, if you have to use a GOTO and I don't mean JSR in assembler, your
> >> solution is neither elegant nor worth repeating. ;-)
>
> Technically, (Read as, I am just trying to stir up trouble ;-) ) JSR is
> not a goto in assembler but a GOSUB because it pushes the address of
> the next instruction after the JSR on the stack before it jumps so that
> a RET can pop it off of the stack at the end of the routine to start
> executing where the JSR had left off.
>

Hummm --- sounds like a COBOL alter statement to me.... ;-)

bozon wrote:
> Michael Segel wrote:
>
>>>BTW, if you have to use a GOTO and I don't mean JSR in assembler, your
>>>solution is neither elegant nor worth repeating. ;-)
>>
>
> Technically, (Read as, I am just trying to stir up trouble ;-) ) JSR is
> not a goto in assembler but a GOSUB because it pushes the address of
> the next instruction after the JSR on the stack before it jumps so that
> a RET can pop it off of the stack at the end of the routine to start
> executing where the JSR had left off.
>

Aha! but are you and Uncle Mikey talking about the same assembly language? ;-)


--
Ciao,
Marco
__________________________________________________ ____________________________
Marco Greco /UK /IBM Standard disclaimers apply!

Structured Query Scripting Language http://www.4glworks.com/sqsl.htm
4glworks http://www.4glworks.com
Informix on Linux http://www.4glworks.com/ifmxlinux.htm

Marco Greco Said>
>Aha! but are you and Uncle Mikey talking about the same assembly language? ;-)

I thought there was only one kind, MC6809 ;-)

http://www.techheap.com/processors/6809/6809.html