But as you said, explicity closing the connection will require opening a new connection for each method which may incur in some performance. Instead, why don't we let the ConnectionManager do its job on reusing connections keeping the number of open connections to a minimum. Ideally, if we are not overlapping operations, there should be only one open connection. So we don't worry about having to close it.
Actually, I've been working on a filesystem for NetBeans and I wanted my whole filesystem to share only one connection with each FileObject using a WebdavResource instance. I wasn't sure if a FileObject would be accessed simultaneously by different threads in Netbeans so I modified WebdavResource as explained earlier. Actually the deadlock problems I was having may have not been related to WebdavResource but anyway I using that way now and I haven't noticed any problems but I haven't validated that actually works as expected.
I can provide a patch if interested but I need to update it against the latest version from CVS.
Carlos
Ingo Brunberg wrote:
Of course this will work, and I have metioned this possibility many times. But it will not physically close the connection either. Calling releaseConnection() just makes sure that the connection can be safely reused.
Ingo
How about using the MultiThreadedHttpConnectionManager and then calling method.releaseConnection() after executing each method in WebdavResource.
For example, a typical fragment in WebdavResource:
int statusCode; try { statusCode = client.executeMethod(method); } finally { method.releaseConnection(); } setStatusCode(statusCode); return (statusCode >= 200 && statusCode < 300) ? true : false; }
Will this work?
Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
