Hmm, there are multiple solutions to that: 1. read the stream in mem and use a bytearrayinputstream if it fits 2. store a pointer (id) to the record and reopen it if needed at read time 3. something in between (like tolerate to load in mem 1M and rest is done with the pointer impl
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 1 avr. 2021 à 09:50, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > hi! > > While working on SQLServer tests I came across a clarification in JDBC4 > that reading a LOB via InputStream _is_ possible, but you have to consume > that stream before you get the next attribute. ANY further get on the > ResultSet will close the open InputStream per spec. > > This has an effect on our 'extended' non-portable feature > > @Persistent > private InputStream stream; > > This is basically not possible anymore per JDBC4 spec is my interpretation. > Because if we get a List<InputStreamLobEntity> with 10.000 entries, then > we would have 10.000 InputStreams open. That's of course a bad idea, and I > fully understand that JDBC4 clarification. > > Should we get rid of those tests and feature? > It was only avail on 4 databases anyway. > Tests are > TestInputStreamLob and > TestReaderLob > > Wdyt? > > LieGrue, > strub > > >
