Re: problem with LargeObject and commit - Mailing list pgsql-jdbc
From | Marc Cousin |
---|---|
Subject | Re: problem with LargeObject and commit |
Date | |
Msg-id | 2155001.o66iMCTO3Y@marco-dalibo Whole thread Raw |
In response to | Re: problem with LargeObject and commit (Dave Cramer <pg@fastcrypt.com>) |
Responses |
Re: problem with LargeObject and commit
|
List | pgsql-jdbc |
Sorry, I don't think I get it, so please correct me below if I didn't. I currently use getInputStream() on my large object. How could I provide a connection to the extended InputStream ? I am calling a LargeObject method. Or maybe extend LargeObject to have a new getInputStream method with a connection provided, and then provide this connection to the extended InputStream ? My initial idea was to not have to provide the connection as a parameter, so I wanted to use the Lob Manager. Anyway, shouldn't streaming a large object in this special case be easier to do ? The original code (from SQL Server) didn't have to do all these workarounds, and I'll get this objection from people that will have to use this code :) Just having conn as protected instead of private in the LargeObjectManager would have made it possible to me to do it simply: I could have provided the connection to my extended LargeObject, and from there end the transaction on close(). Regards. On Monday 30 September 2013 17:08:18 Dave Cramer wrote: > Marc, > > You required the connection to create the LargeObjectManager, so why not > just extend the InputStream and add the connection to that object. > When you close the input stream, close the connection ???? > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > On Mon, Sep 30, 2013 at 11:18 AM, Marc Cousin <cousinmarc@gmail.com> wrote: > > Hi, > > > > I'm having the following problem: I need to stream a LOB to a web client, > > without consuming > > a lot of memory. So I am returning getInputStream() to the caller. > > > > This works perfectly, except that I have to keep a transaction open to > > return the large object > > stream, and I have (or found) no way of closing the transaction when the > > filestream is closed. > > > > So of course, if I did that, I would get a lot of IDLE in transaction > > sessions... > > > > So the logical way seemed to me to extend LargeObjectManager and > > LargeObject to have a > > close method on my LargeObject that closes the transaction, meaning that > > my LargeObject > > should have a connection attribute. So I wanted to do something like this > > (not working, > > it's just for the sake of explanation): > > > > > > public class StreamLargeObjectManager extends LargeObjectManager{ > > > > public StreamLargeObject openStreamLargeObject(long oid, int > > > > mode) > > > > throws SQLException > > > > { > > > > LargeObject lo = super.open(oid, mode); > > StreamLargeObject so = new StreamLargeObject(lo, > > > > super.getConn()); //cannot be done because no access to connection > > > > return so; > > > > } > > > > } > > > > > > and > > > > public class StreamLargeObject extends > > org.postgresql.largeobject.LargeObject{ > > > > Connection conn; > > > > LargeObject lobj; > > > > > > public StreamLargeObject(LargeObject lg, BaseConnection conn) > > > > throws SQLException { > > > > this.lobj = lg; > > this.conn = conn; > > > > } > > > > > > @Override > > public void close() throws SQLException { > > > > lobj.close(); > > this.conn.commit(); > > > > } > > > > public getInputStream() throws SQLException > > > > { > > > > return lobj.getInputStream(); > > > > } > > > > } > > > > > > As the comment says it all, I cannot do this: conn is private in > > LargeObjectManager. For now, the problem has been > > worked around by duplicating all the LargeObjectManager code, but this is > > obviously ugly and not > > maintainable. So my question is: have I missed some obvious solution ? > > Could a getter be added to > > the LargeObjectManager's connection ? > > > > Regards, > > > > Marc > > > > > > -- > > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-jdbc
pgsql-jdbc by date: