New significance of holdable result sets in Java 8

As of the release of Java 8 and its Streams API a new door has opened for many things, including an important
improvementin the way RESTful services can be implemented. Let me briefly describe the architecture with Spring's REST
support:an MVC framework is used where the Controller dispatches the HTTP request to a Service method; the Service
methodcontacts the database and returns a Model-oriented representation of the response; the View layer then transforms
itinto the actual HTTP response bytes. 

Data is passed from Controller to View as the return value of a method. Traditionally, if you wanted a
collection-shapedresponse, you would return a List. This meant eager loading of all data needed for the response, which
causedscalability issues related to the JVM heap space. 

With the Streams API it is now very convenient to return a lazily-evaluated stream of Model objects. It is also very
convenientto make this stream pull data directly from an underlying ResultSet, tronsforming each row on-the-fly into a
Modelobject. This, however, calls for holdable result sets because the transaction commits when program control leaves
theService layer. 

The Spring team has recognized the relevance of the above use case and with release 4.1.2 they have introduced a
specificenhancement needed to support result sets holdable into the View layer (albeit only when JDBC is used over
Hibernate).This is described in the issue SPR-12349 [1]. Spring also plans to support this use case with additional
helpercode which turns Hibernate's ScrollableResults into a Stream (SPR-12388 [2]). 

The above could raise the level of interest of the PostgreSQL JDBC team in implementing holdable result sets backed by
nativeholdable cursors instead of the current client-side cursors, which don't allow the space complexity to be reduced
fromO(n) to O(1) on the JVM side. I am aware that this is not a trivial endeavor as it requires intervention into the
FE/BEprotocol, but I would nevertheless propose that this concern be reassessed in the light of new developments in the
Javaecosystem. 

Regards,
Marko Topolnik



 [1] https://jira.spring.io/browse/SPR-12349
 [2] https://jira.spring.io/browse/SPR-12388