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
Art, The main purpose of a cursor is to maintain a position in a table so that you can get the next/prior record. How does that play in this? Would the cursor remain open? Would this function somewhat like a queue? Or are we simply talking about a persistently prepared statement or rather persistently declared cursor type of thing??? "Art S. Kagel" <kagel@bloomberg.net> wrote in message news:43D95A67.1030502@bloomberg.net... > 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
In response to all this chatter about new features: How about the development team actually get on and fix all the outstanding (customer raised) bugs? As a developer myself I understand that green-field development is always more interesting than bug fixing, but surely satisfying current customers should be a priority over adding "wouldn't it be nice" features to try and entice new customers to a (supposedly dying) product. To have no movement on 12 bugs in almost two years is extremely frustrating! Regards, Donny (Still waiting for: 164051, 164052, 164053, 165994, 165995, 166894, 168482, 168483, 171075, 171076, 171080, 171079.)
Madison Pruet wrote: > Art, > > The main purpose of a cursor is to maintain a position in a table so that > you can get the next/prior record. How does that play in this? Would the > cursor remain open? Would this function somewhat like a queue? Or are we > simply talking about a persistently prepared statement or rather > persistently declared cursor type of thing??? OK, let's see if I can clarify my thinking on this. What I'm looking for is in part something like what a transaction monitor like BEA's Tuxedo and IBM's Encina provide, but without the overhead and headache of a separate entity between the clients or middleware and the IDS instance. I want to be able to establish a logical session which is independent of any physical session and be able to disconnect one physical connection session from the logical session and connect another physical session to the logical session and continue working with it. Existing prepared statements, cursors, and open transactions established in the logical session would continue uninterrupted. There would only ever be one 'current' physical session attached to the logical session. Any physical session could attach and detach to only one logical session at a time but would have access to attach to any logical session for which it knows the session id. This would permit the maintenance of session context across multi-tasking and multi-threaded logical applications such as middleware, application servers, and WEB servers without the need for a physical connection to the server for each logical session and without the need to shuttle a user request to the specific instance of middleware maintaining that user's context. Obviously there are other features and requirements that become part of the package (like the ability to establish a new logical session when a physical session has no current session) but the concept of a sharable logical session is the basic requirement from which the rest flows. The logical session provides the ability to develop new applications for the WEB and other client server applications that are not currently possible. You want a way to establish IDS as an industry leader? Here is one major way: make it THE platform for an entirely new development paradigm. In the process you'll make my life far easier. Art S. Kagel > > "Art S. Kagel" <kagel@bloomberg.net> wrote in message > news:43D95A67.1030502@bloomberg.net... > >>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 > > >