-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
>
> -----------------------------
> Please read the FAQ!
> <http://java.apache.org/faq/>
> -----------------------------
>
> Hi again;
>
> >Actually the lack of integrity constraint checks is a performance
> >benefit. If you are writing All the code that hits the database
> >then you only need to worry about how good you are ;-) A
> database that
> >lacks integrity constraints is really only a liability in an
> >environment where multiple programmers/applications need to
> access the
> >db.
>
> That is what I am scared of, especially in a situation like
> this (where
> there are lots of concurrent transactions occuring), the
> database might
> screw-up and this will cause serious problems. HTTP session is much
> more safer I guess.
It's not the data activity that's a danger it's the programmer activity -- making sure
each programmer understands the mechanisms
you (or the dba) has put in place to ensure referential integrity etc.
If you are not concerned with persisting your data over the course of time then you
needn't worry about the database aspect of
things anyway.
> >I'm sure others will chime in but as far as dynamic data goes 200k
> >should be a fairly trivial amount. Hashtables are quite efficient
> >for information retrieval.
>
> Thanks for the input. I was scared of memory it consumes, I mean it
> might consume too much memory which will in turn cause swapping, etc.
>
>
> >> Also, when I can't use a cookie and encode the URL for transferring
> >> User ID between requests, the URL becomes something like
> >> http://www.xxx.com/JSERVUID=some_junk_data. Do you think this
> >> is secure
>
> >As opposed to what?
>
> I mean, is it secure for users to see the sesson ID's ? Cause, if you
> get the session ID of someone else, you can see all the data that
> belongs to that user and I don't know how well Java encodes this
> session id with EncodeURL function.
Yes that is correct. If you are concerned about security you'll have to use something
like SSL anyway.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
