Re: Another IDS Feature Request

Art S. Kagel wrote: > 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! > Yes this would be nice to replicate cursors (this would be a nice extra but if it kills the whole feature I could wait on it) what would the syntax be: connect to global cursor <global_ID>@<instance_name> ; or would the global_ID be really global accross all ER instances. I am happy either way. Although there may be hang ups if you have to know what machine a cursor was on before you connect to it. Of course now I am understanding what you want is to replicate the cursor across the ER databases so that if one ER goes down you can connect to the cursor on another instance or if you are very redundant the next time you access the query you will happen to access it from an unknow ER replicant and you just don't care because you know it was replicated. Very nice indeed. > > 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. Thanks, this is what I was thinking to. Art S. Kagel wrote: > bozon wrote: > > 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 be> handled by connecting to the session then doing a disconnect instead of a > detach. I was thinking that a sql command would be more appropriate since if you have a global ID you can get to it from any session so: dbacces <database> >>EOF close global cursor <global_ID>; or dissconnect from global cursor <global_ID>; EOF would be how I would see it. >Someone mentioned a timeout, but, unless that were configurable, I > don't like that. Yes, if it is configurable I am fine with 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