RE: Another IDS Feature Request
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 >