Re: Another IDS Feature Request

Art S. Kagel schrieb: > 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 yes, I like it! I reply to your original post, Art, because I want to sum it up a bit. Maybe it helps if we start reading about CICS + IMS/DB in those dusty very old manuals and then switch over to the INFORMIX XA guide. You have it all there - including heuristics of 2way commits or even 2+ way commits and a way to cancel it all asynch & from outside (like using an intelligent onmode -z) While reading the XA guide keep in mind, that you are allowed to be 'your own coordinator' (ER-group wide that is) - it is not necessary in using XA to synch a sequence of SQL activities on DIFFERENT machines or on databases having DIFFERING contents. The detailed view is more complicated, though. But that is the term transaction monitoring as in Encina, Tuxedo, UTM and friends..... So here we are: Welcome to the post hype times. Choose 2 out of 3: - persistent DB connections for the client sessions - simulated 'keep alive (as in applet containers)' and disconnect / reconnect to 'my' session in a stateless model - performance dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe