> i want to store it in stringbuffer object .
That's probably not a good idea. You're running out of memory with your current settings, which suggests that storing 50,000 records in memory isn't a feasible option. What do you plan to do with this data (presumably you don't want to store it in a StringBuffer just to leave it there)?
~
> so if u want to have 500
> initialze the string in constructor with 500 spaces like " "
> i guess that would help you
That's extremely poor advice.
If you can't help, don't hinder.
[url=http://www.catb.org/~esr/faqs/smart-questions.html#id274601]How To Answer Questions in a Helpful Way[/url]
~
hi
After reading 50000 records i want to write it in xml or excel file.
At the same time i want this object should be available in session obj so that no need fire database query again . But i unable to store it in session object becuase of out of memory error . I have increased size of JVM to 1GB but still it cannot store this heavy StringBuffer object .
I stucked at this problem.
regards
vijay
> At the same time i want this object should be available in session obj so that
> no need fire database query again.
Aha. Then given the trade-off between memory usage and database access, you chose memory usage. But in this case I think you chose wrongly. It's pretty clear that you don't have enough memory to support that choice. Given that, I would drop the idea and rerun the database query.
However several other posters have wondered why you chose a StringBuffer object to store a large amount of data. I think it's a strange choice too. Perhaps a different choice would have required less memory. Would you like to post the code that produces that StringBuffer?
Hi
Out of memory issue is may be because of shortage in memory allocated for JRE
You can increase run time memory by using following command
java -Xms64m -Xmx512m classname
Also I dont think there is a limit for StringBuffer. But stroing such large objects StringBuffer is not a good idea, instead of that we have Vector,ArrayList,HashMap etc...
> Out of memory issue is may be because of shortage
> in memory allocated for JRE
Yep, you read it here first folks. 'Out of memory' may be because of a shortage of memory. Remember that now children. It could be important.
Today must be Tautology Wednesday.
> Also I dont think there is a limit for StringBuffer.
So read the thread and discover your mistake.
> But stroing such large objects StringBuffer is not a
> good idea, instead of that we have
> Vector,ArrayList,HashMap etc...
More nonsense. They will save memory over StringBuffer how?
Thanks ejp.
I would like to add...
> Hi
> Out of memory issue is may be because of shortage
> in memory allocated for JRE
> You can increase run time memory by using following
> command
>
> java -Xms64m -Xmx512m classname
Wow, really? U think? Why didnt any of the other replies say that!! And why if the OP said 1Gb was not enough would you suggest 0.5Gb?
>
> Also I dont think there is a limit for StringBuffer.
> But stroing such large objects StringBuffer is not a
> good idea, instead of that we have
> Vector,ArrayList,HashMap etc...
Vector? Vector? You running JDK1.1?
Ted.
I'm pretty sure the OP would also save a lot of memory if he wouldn't store an XML file of some data set in a StringBuffer, but would actually use some OO to create an object model. I'm quite convinced that an object storing two int values is much smaller than an XML entity storing two int values.
Object:
20 bytes + 2 * 32 bytes = 84 bytes.
XML:
<SomeObject>
<field name="first" value="12345678"/>
<field name="second" value="0000"/>
</someObject>
= about 100 chars = about 200 bytes.
Not handling data as data is usually fairly stupid IMO.
Another point: the OP is storing large amounts of data (be it in a StringBuffer or in some other form) in session data. Couldn't it happen that the server will dehydrate that data (is that the verb?) into its own database anyway? Shouldn''t one be careful with solutions that cache large results in session data? What's the best practice?
> Maybe this will help:
>
> http://vtd-xml.sourceforge.net/
That's the thing about XML. Just when you think you know what's out there,
someone looks at code you've sweated blood over and they say:
the new XYZ XML technology can do this better, and in one line of code.