Re: Another IDS Feature Request

bozon wrote: > It would help us. I think it would be a feature that would really fit > in with the new redundant fault tolerant application structure that is > popular today. <SNIP> That raises an additional, related request. That the global cursor ID be sharable across ER replicants. That would allow cost free failover to a backup server! > To use this feature we can include some secure link to the cursor on > the web-page, so that the next connection will know which cursor to > connect to. (I think we could come up with a way to do this securely.) > So when the page is submitted the connection can look at the data form > to get the cursor key if it is needed. Not hard. Store the cookie->cursor mapping locally on your servers, even in a database table. > I just talked to one of my developers and he mentioned that you would > also want some way of closing the cursors externally. His example is > that a user has many choices on a screen not all of them would end up > paging through the cursor. In this case he would hate for all of the > code to have to handle server side global cursor cleanup if the cursor > was no longer needed. We could just create a job to determine that any > cursor older than 3 hours should be closed. (We would create a table > that stored the creation time and global cursor ID along with the > secure ID that we would pass around.) Yes, a related thing would be an analog to onmode -z and onmode -Z, say onmode -g <global sessionid>, and an SQL level interface, but that could behandled by connecting to the session then doing a disconnect instead of a detach. Someone mentioned a timeout, but, unless that were configurable, I don't like that. For efficiency the server could suspend a logical global session releasing its resources. Attaching to a suspended session would take longer to reload the context, but doable. Art S. Kagel