From: "elehti@..."
Can you please explain how your team achieved Persistent Sessions
in DB connection for QZDASOINIT. That is incredible.
Eric,
If it sounded incredible, it makes me wonder if we're talking about the same thing, because the idea I tried expressing is simple, and really not that hard to implement. And your references about the Java JPA specification really makes me wonder if we may be thinking about different things. My java colleagues didn't implement an object-relational-mapping solution, although they were looking at Hibernate.
My java colleagues implemented a solution for working with lists, and provided paging comparable to what you'd see in a traditional 5250 subfile screen, including prompts to position to rows by key value, and prompts to goto specific pages; or first, prior, next, and last page navigation links. A typical page would consist of 12-20 rows, though the result set might contain thousands.
They were using standard JDBC connections, which activated QZADASOINIT prestart jobs for each open connection. Rather than sharing that connection with multiple users, each user was provided their own connection, so that the state of SQL result sets in QZDASOINIT jobs were preserved from one request to the next, for each user. My colleages wrote a "connection manager" class for managing the connections. But the jist of it was that each individual user had their own connection, which remained opened and dedicated to that individual until an "Exit" link was clicked, or a period of inactivity had elapsed.
So rather than evoking a new SQL select statement to implement page navigation, they just fetched next or prior sets of rows from the current cursor.
My Java colleages were actually following a pattern that I was using in RPG based web applications, except I was using an SQL CLI interface instead of the QZDASOINIT interface. To be frank, we were developing interfaces that competed against one another. I personally prefer using RPG for Web applications.
Nathan.
midrange.com
