[Cosmo-dev] bug 5078: read put request content into a tmp file and compare the]

[Brian Moseley]

On 10/17/06, Jared Rhine <jared at wordzoo.com> wrote:

> Ok, has 0.5-SNAPSHOT been reading into memory?

yes. don't confuse two issues:

1) before now, we passed the socket input stream directly to the data
access layer; now we read the socket input stream, write to a temp
file, and then pass a file input stream on that file to the data
access layer. no more or less memory reading than before.

2) in the data access layer, from whichever input stream was given to
us, we read the content into memory, parse and validate it if it's
icalendar, and then (effectively) hand off the memory-based content
to the jdbc driver as part of a sql insert.

> Are the resources bodies being put into mysql?  Can you sql select the
> length of the resource?  Can the mysql update be streamed?

1) yes. that's how we can regurgitate the octet-equal resource body on gets.

2) yes, but that doesn't help with the "did we read enough data from
the socket" test, because that needs to happen before we try to save
anything into the database.

3) unknown. would be really nice if we could provide an input stream
to hibernate/the jdbc driver for blob attributes rather than a byte
array, but that doesn't get around the fact that at some point we do
have to parse and validate icalendar content, and that requires us to
consume the socket input stream and give something else to hibernate.