Jerome I concur with your regarding the scalability/threading issues surrounding the servicing of streaming output
ala Servlet, we should avoid this at all costs, so +1 on the asynch processing model.
- Larry
From: Jerome Louvel
Sent: Thu 3/6/2008 4:17 AM
To: dev_at_jsr311.dev.java.net
Subject: RE: JSR311: Response isn't adequate
Hi all,
Let's me jump in the middle of the discussion. I agree that the support for
large bodies is important for JAX-RS and that there needs to be a way to
stream some dynamic content (blob or anything else).
I understand the issue with opened transactions but I don't think that the
idea to give a direct blocking access to the outputstream is good. It shifts
a problem coming from the EJB transaction model into the JAX-RS API.
Also, it will prevent optimal usage of NIO in those cases as it will require
one thread is blocked per request, until the response is fully written.
It is more efficient to let the HTTP layer pull the content as needed. Let's
try to not reproduce the same Servlet API design issue again. For background
info, see:
http://blogs.webtide.com/gregw/2004/09/24/1096051860000.html
When we designed the Restlet API, we were extremely careful about this
aspect. This allows us to have a fully asynchronous processing model on the
server-side as well as on the client-side. See:
http://www.restlet.org/about/introduction
I think that the transaction should be left open by the EJB container (using
the deployment descriptor as explained by Larry I think). The message body
writer could perfectly manually close the transaction once the writing is
done, either by overriding the close() method as suggested by Paul or by
overriding a new release() method on the MessageBodyWriter interface.
Best regards,
Jerome Louvel
--
Noelios Consulting
http://www.noelios.com
> -----Message d'origine-----
> De : Larry Cable [mailto:lcable_at_bea.com]
> Envoyé : vendredi 29 février 2008 20:26
> À : dev_at_jsr311.dev.java.net
> Objet : RE: JSR311: Response isn't adequate
>
> I agree with Bill, both Servlet *and* this JSR require a
> mechanism to allow streaming/chunking to the
> response output stream ... best to fix this in 1.0 as fixing
> it in 3.0 (ala Servlet) is a bit like making
> unthreaded, non reentrant code in the C locale, MT-hot and
> I18N-ized at the same time!
>
> :)
>
> - Larry
>
> ________________________________
>
> From: Bill Burke
> Sent: Fri 2/29/2008 10:20 AM
> To: dev_at_jsr311.dev.java.net
> Subject: Re: JSR311: Response isn't adequate
>
>
> Marc Hadley wrote:
> > On Feb 28, 2008, at 12:10 PM, Bill Burke wrote:
> >>
> >> And I've already told you that this just not cut it for
> specific use
> >> cases (Blobs). It is going to make EJB integration(really anybody
> >> that uses JTA) unusable in those cases. I don't think Lobs are an
> >> unreasonable use case to support.
> >>
> >>> - In a servlet container you can inject
> HttpServletResponse and use
> >>> the OutputStream from that but you'll have to set any headers
> >>> yourself before you commence writing.
> >>
> >> So, anything that doesn't fit the @Provider model, we'll have to
> >> escape to Servlet API or worse, have our own vendor
> specific extension
> >> for? Hmmmm...All because we can't inject an OutputStream.
> >>
> > I'm not I understand why blobs don't fit the provider model
> ? If the
> > provider runs in the same connection+transaction scope as
> the resource
> > method and can be injected with all the same stuff what
> doesn't work ?
> > Sorry if I'm being dense here.
> >
>
>
> That's the thing, the provider has to run in the same
> transaction scope
> as the resource. Every container I know that does
> transactions usually
> ends the transaction before a response is sent back to the client.
> (a.k.a EJB TransAttribute.REQUIRED). You basically wouldn't
> be able to
> use container managed transactions. Are you following me? I
> don't know
> if I'm being clear.
>
>
> > Injecting an OutputStream is only half the work, if you
> still want to be
> > able to use Response to specify headers then you'd either
> have to call
> > that first and somehow pass that to the runtime then start
> writing to
> > the output stream or we'd have to buffer the output waiting for the
> > method to complete and return the response. Again, sorry if
> I missed
> > something, I'm still catching up from a few days vacation.
> >
>
> Don't want the buffering. That could be done in the current
> model. I
> want the ability to stream LOBs and again, some DBs require a
> connection
> to be open while you're reading a LOB.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
> Notice: This email message, together with any attachments,
> may contain information of BEA Systems, Inc., its
> subsidiaries and affiliated entities, that may be
> confidential, proprietary, copyrighted and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.