Re: Another IDS Feature Request

Madison Puet said> >Or are we simply talking about a persistently prepared statement or rather persistently >declared cursor type of thing??? I am the one who asked for persistently prepared statements. Art's feature and the persistently prepared statement feature that I asked for are a result of a new software architecture resulting from serving web pages. (I can smell product differentation from DB2 now.) Basically, we have a typical web application any number of app-servers connected to the database running tomcat. Each app-server has many connections to the database. Any request from a user can be handled by any app-server and any connection. State is not saved so you won't have access to a cursor again for a second request because it may not exist on your app-server or your connection. This means that currently we can't really prepare statements effectively nor use cursors for multiple requests (paging through data as one example.) So we end up using first and skip and ordering the data for each request. So Art's request is to have that cursor server-side data structure accessable with some kind of handle so that other connections can use it. You would want all of the positioning information retained, so that the next request could start where the other had left off.

bozon wrote: > Madison Puet said> > >>Or are we simply talking about a persistently prepared statement or rather persistently >declared cursor type of thing??? > > > I am the one who asked for persistently prepared statements. Art's > feature and the persistently prepared statement feature that I asked > for are a result of a new software architecture resulting from serving > web pages. (I can smell product differentation from DB2 now.) > > Basically, we have a typical web application any number of app-servers > connected to the database running tomcat. Each app-server has many > connections to the database. Any request from a user can be handled by > any app-server and any connection. State is not saved so you won't have > access to a cursor again for a second request because it may not exist > on your app-server or your connection. > > This means that currently we can't really prepare statements > effectively nor use cursors for multiple requests (paging through data > as one example.) So we end up using first and skip and ordering the > data for each request. > > So Art's request is to have that cursor server-side data structure > accessable with some kind of handle so that other connections can use > it. You would want all of the positioning information retained, so that > the next request could start where the other had left off. > Precisely and concisely said. Art S. Kagel