Well, we can play semantic games.
Paing IS solely a UI manifestation. For example, I don't know of any order posting routine that wants its line items in pages.
And, for good or ill, it is performance dependent. Getting and/or caching 10-20 rows is essentially a "free" operation all said and done.
But at some point, the numbers of rows pass the "this is too slow" intangible point.
To address your point, tho, there is really no reason why the persistence layer can't implement, as an optimization through a configuration option, a paging lazy loader.
Toplink, for example, offers the feature that if you pass a unmanaged object via reference (i.e. to a class in the WAR from a Session Bean), it still maintains its lazy load behavior, even though it's not officially managed. I think it wouldn't be a horrible hack to tweak that code to be page senstive, so that when you iterated from objectItems[10] thru [20], the lazy loader is smart enough to load, say, 2 or 3 blocks of rows of data.
But a lot of it really depends on the JDBC implementation. Just because you can specify a scrolling cursor to the DB (a typical mechanism to implement something like this), doesn't mean it performs well. It would be rather yucky to have the driver load the first 1000 rows so it can show rows 1000-1010.
But that doesn't mean that they couldn't offer such functionality thru the Toplink implementation, so that if you DB and JDBC driver support such paging like queries well, you'd be able to leverage them.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244917