W3C home > Mailing lists > Public > www-jigsaw@w3.org > May to June 1997

Re: Where to plug in after reply is sent (fwd)

From: Joseph M. Futrelle <futrelle@ncsa.uiuc.edu>
Date: Tue, 24 Jun 1997 12:50:55 -0500 (CDT)
Message-Id: <199706241750.MAA00940@pecos.ncsa.uiuc.edu>
To: www-jigsaw@w3.org
Mark Friedman spake thusly:
> From mark@intraspect.com Tue Jun 24 12:08 CDT 1997
> I'm creating my own InputStream for my resource's replies. That
> InputStream reads data from a database and I need to assure that the DB
> transaction gets closed after all the data is sent back. At first I
> thought that I could close the transaction in the InputStream's close
> method, but looking at the code in Client.java, I'm not convinced that I
> can count on the stream being closed (i.e. there doesn't appear to be a
> "finally" that closes the reply's stream) so I would like to know if
> there is any other place that I can put my transaction close code which
> is guaranteed to be called after the reply's InputStream has been read
> and its contents have been sent back to the browser.

So do you mean that you call reply.setStream and exit get (or whatever
HTTP method you're defining), and then the *stream* makes DB transactions?

We do a lot of DB access through HTTP resources and we always do DB
access *before* we emit the reply. This is a conceptually cleaner
model. Do you have a special reason not to do this? (e.g. you're doing
something SSI-like?)

> Ideally, I would like a method that I could overload which would wrap
> around the entire Reply generation and Reply emitting process and
> therefore be able to do my own exception catching (I need to know
> whether I should rollback or commit the DB transaction) and transaction
> processing. Would Client.startConnection() be the appropriate method?
> Could I just subclass w3c.jigsaw.http.Client and write my own
> startConnection() which wrapped my stuff around a call to
> super.startConnection()?

It's better not to have to roll back a transaction merely because a browser
closes a connection. Or is that what you're trying to do?

Sorry I can't be more help, I think I still don't get what your situation

Here's a philosophical question: what's the significance of knowing
that you're done sending a reply on the socket? There's no guarantee
that the browser will read it.

> Joseph M. Futrelle wrote:
> > Mark Friedman spake thusly:
> > > Is there any method I could define or override to get something
> > executed
> > > after the reply that my resource creates is sent over the wire?
> >
> > What do you mean, "after"? Could you explain the specific situation?
> >
> > You can always spawn a thread and have it sleep. But you'd want to be
> > careful
> > that you don't just blindly spawn threads whenever a request comes in,
> > because
> > that would be a potential avenue for a denial-of-service attack.

Joe Futrelle
Developer, EMERGE Joule/Jigsaw Java/HTTP
National Center for Supercomputing Applications
futrelle@ncsa.uiuc.edu (217) 265-0296
Received on Tuesday, 24 June 1997 13:51:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:31 UTC