[thelist] Passing a very large data session-wide.

Thu Sep 8 16:06:16 CDT 2005

So the consensus I get from this discussion is that storing it in the
DB is far better than storing it in session and it is probably better
than storing it in the file system.

I think we shall try storing it in the db as a blob type. If we fail
for some reason, or observe a performance degredation, altering the
code so that it stores the data in FS will not be a very big issue.

How the data can be changed/damaged/altered by people is yet another
story. You cannot believe how imaginative a nasty client/agent can be
:)

Cheers and Thanks for all your comments.
Volkan.

On 9/9/05, VOLKAN ÖZÇELİK <volkan.ozcelik at gmail.com> wrote:
> >Why not store it in a database, then delete the record when the
> >transaction has succeeded? Surely given your environment this is faster
> >than accessing the filesystem twice, and should scale better than
> >storing it in the session.
> 
> This may be an option too.
> 
> It should be Typically in the form:
> 
> UID (autoincrement)  |   SessionID(varchar-primary)  |  Actual
> Data(BLOB or Text whatever)
> 
> i guess.
> 
> Let me try to explain the file a bit more.
> 
> The file looks like.
> 
> <html>
> ...
> some css for @media print and @media screen.
> ...
> <h2>heading of section 1 which is gathered dynamically</h2>
> <table>...<td>some static content here ... some dynamic content from db</td>
> <h2>heading of section two</h2>
> <table>... <td>
> 
> <table>
> ... lots of numbers and data rendered within a
> <td><pre>dynamic data</td></table>
> 
> ...yet another table
> notes, disclaimers and references retrieved from db.
> 
> </html>
> 
> I cannot give very much detail due to confidentiality issues.
> 
> The final html is a legally approved copy (people pay money for it)
> and we have to store it "as it is" somewhere (it's nonsense but "as it
> is" means including the css and javascript references in the file as
> well :) ).
> 
> >
> > Just how big is this puppy (file) going to be?
> >
> 
> A few hundered KB's, at most one megabyte I hope.
> 
> We have other sorts of files which are 10-50KB size (report files) and
> we use the gzip approach with them. Though those files are not very
> frequently generated and thus do not bring an overhead. Plus, they are
> generally created via a scheduled task which execute from midnight to
> early morning.
>