Re: where do you store app wide data?
From: worzel (asda_at_sdarta.com)
Date: 01/07/05
- Previous message: Perlana: "Question about fpassthru function"
- In reply to: Wayne: "Re: where do you store app wide data?"
- Next in thread: Wayne: "Re: where do you store app wide data?"
- Reply: Wayne: "Re: where do you store app wide data?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 7 Jan 2005 09:29:47 +0800
re:
Not the JVM.. Java applications.
Well, thats the fault of whoever wrote the application - not Java.
re:
Combine a language where everything
> is stored on the heap, has an insane number of objects for any task
> (small example: open a file) with garbage collection and you get
> something that's a memory hog.
I guess its all relative - to the amount of memory you have, and what you
are used to using. Of course, the things you consider to be a downside are
considered to be an upside to others - so again, its all relative.
re:
> The "notepad" swing example app that comes with the JDK takes up more
> memory than the newsreader I'm using to write this message.
You mean the notepad swing example and JVM take up more space than your
newsreader minus a JVM? Anyway, I can see your point about the memory use. I
guess I am just not apprecaiting why you see it as a problem when most
people stopped talikng that way about Java a couple of years ago. (and why
it has since become so hugely adopted in the industry as an enterprise
solution)
re:
>>Only really need proof when something is in doubt :)
>
> Exactly.
I should have seen that one coming :)
re:
Adding
> your own caching in RAM is redundant.
Sure, if it already being done for you. But this is not always the case.
Files are not stored in RAM when you close them. Connections (which to MySQL
users are inexpensive to create, but to Oracle users are humongously
expensive to create) to a database are not stored in RAM unless you
pool(cache) them. A custom 'ApplicationManager' object that you might create
is not stored in RAM unless you put it there, Any factory objects you need
will not automatically be stored in RAM, and so on....
As I said, it is just a conveninece -a standard way of doing such things.
Anyway, no point arguing - I have no choice but to live without it and
learn to do things the way you PHP boys do it. I must admit though, its
given me pause for thought as to think twice before I automatically do it in
Java in future. Using the one langugae so much of the time, you kind of do
slip into little comfort zones - techniques that feel comfortable are used,
even though they may not neccasarily be the best way to go.
"Wayne" <not@here.com> wrote in message
news:3qsqt0tvsgfpke6f1dj910hstv1ljjasb0@4ax.com...
> On Thu, 6 Jan 2005 11:03:16 +0800, "worzel" <asda@sdarta.com> wrote:
>
>>Again, not sure where you get this idea from?
>
> Running any sort of Java application.
>
>>If you are saying that an
>>instance of the JVM itself is a memory hog (which you seem to be) then I
>>would have to say you are quite wrong.
>
> Not the JVM.. Java applications. Combine a language where everything
> is stored on the heap, has an insane number of objects for any task
> (small example: open a file) with garbage collection and you get
> something that's a memory hog.
>
> The "notepad" swing example app that comes with the JDK takes up more
> memory than the newsreader I'm using to write this message.
>
>>> You know the only way to prove that is to build a Java application and
>>> PHP application and see which is faster..
>>
>>Only really need proof when something is in doubt :)
>
> Exactly.
>
>>> Since I've never done Java web development -- what exactly do you
>>> store in the application state anyway?
>>
>>If the data is to persist across the life
>>span of an applications, it goes in app scope.
>
> See this is interesting. I don't see web application as having a life
> span. It's always on. Given the simple counter as an example; if you
> restart your webserver do you really want the counter to go to zero?
> Probably not.
>
>>The strength
>>(and the difference to what you suggested earlier) is that it all happens
>>in
>>RAM and no file or DB access is required. Also, it is just plain simple to
>>do.
>
> Using RAM for caching is premature optimization. Files are cached by
> the OS in RAM, Database queries are cached by the DBMS in RAM. Adding
> your own caching in RAM is redundant. For database connection pools,
> I let other layers handle that.
>
>>Are you kidding! It drives me nuts! I think I would even prefer Oracles
>>'||"
>>concatentaion operator over a tiny little dot.
>
> I like it. I generally don't even use spaces:
>
> echo 'hello'.$something.'world';
>
> Every other operator is used up -- leaving nothing for concatination
> if it wasn't for the dot. PERL6 has decided to use underscore for
> concatination -- scary stuff.
>
>>As you say though, in the world of web apps that we live in it seems to
>>be yet to come of age.
>
> And given that it's such a broadly scoped language, these seems really
> odd. Maybe having Zope around keeps Python developers from building a
> usable general purpose web framework for python.
>
>>I was amazed to learn that it is used to do game
>>programming and animation and stuff - I had no idea it was as widely
>>accepted and popular as it is.
>
> You can build native looking Windows applications with wxPython (which
> is based on the wxWidgets library for C++ and is a great OO layer over
> Win32). Pretty fantasic stuff. You can even package applications
> into executables. I'm surprised no other scripting languages do as
> much practical stuff for the developer as Python does.
>
>>I would rather brush my teeth with a used toilet brush and then gargle
>>with
>>the toilet water than use Perl, so thats not saying much..
>
> Hehe.
- Previous message: Perlana: "Question about fpassthru function"
- In reply to: Wayne: "Re: where do you store app wide data?"
- Next in thread: Wayne: "Re: where do you store app wide data?"
- Reply: Wayne: "Re: where do you store app wide data?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|