On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Howard, > > On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote: > > I am definitely relying on user HttpSessions, and I do JPA-level > > caching (statement cache and query results cache). pages are > > PrimeFaces and primefaces = xhtml, html, jquery, and > > MyFaces/OpenWebBeans to help with speed/performance. And right > > now, the app handles on a 'few' simultaneous connections/users that > > do small and large fetches/inserts from/into relational database. > > :) > > You can tune the JPA caching, etc. to meet your environmental needs, > etc., so you don't *need* a huge heap. If you find that you need to be > able to improve your performance, you might be able to increase your > cache size if it in fact improves things. > doing this, and just made some code changes to tap a little more into JPA caching, but one of my endusers just did a user operation on one of the pages, and he sent me a screen capture of the nasty eclipselink error that he experienced. evidently, i need to tweak caching or do not use the cache at that point in the app. :) i explained to him that i did some major changes in the app, related to caching... and i told him that it was for 'performance improvement', and told him the same as Mark just told me, Google is your friend (and told him that 'wiki' keyword in the search is your friend, too). :) > > sometimes, i do keep large amount of data in user HttpSession > > objects, but still being somewhat junior java/jsf developer and > > listening to you all on tomcat list and other senior java/jsf > > developers, I want to move some of my logic and caching of data > > from SessionScoped beans to RequestScoped beans. > > You might be able to have your cake and eat it, too. There is an > interesting class called WeakReference that you can use to interact > with the memory manager and garbage-collector. If you have a bunch of > stuff cached in the session, as long as you could re-construct the > cache given some value (like user_id or whatever), you can make the > big, cached stuff in the session into so-called weak-references. If > the GC wants to re-claim memory, it can discard weak references and > the WeakReference object will then point to null. That allows you to > have a nice cache that auto-cleans if you start running low on memory. > very interesting. since i'm using gson to accept some JSON-wrapped data into my app from our public website (static pages and formmail, only, for now, until i integrate it with the web app i developed for personnel, only, for now), i didn't like the warning/msg when tomcat/tomee 'stops'...says that weak reference could not be deleted or something like that (sorry, i forgot exactly what it said). Anyway, i followed some issue in gson's issue tracker (on code.google.com), and someone offered some code to delete gson from weak reference, so i decided to add that to my app, when i shutdown app. so, i do know that the weak reference class is available. really have not 'used' it yet, though. :) i have some things in mind what I want to do with that large session scoped data. I am considering caching it at application level and all users have ability to update that huge List<> and extract data. I was thinking of using @Singleton Lock(READ) to control access. it takes no time at all to search the List<> for the information that it needs, and it takes no time at all to re-populate the List<>. Since we discuss GC a lot on this list, i wonder if you all recommend to set the 'list' to null, first, and then List<> ... = new ArrayList<>(newList), or new ArrayList<>(newList) is sufficient for good GC. > I've written a Filter and HttpSession wrapper that can do that kind of > thing transparently to the application code. I don't actually use it > right now -- it was just a proof-of concept -- but it's a quick and > dirty way to get caching but also save a safety valve. > that's nice proof of concept! I guess i've heard so much bad about people not cleaning up threadlocals, that I try to avoid usage of threadlocal, but it's interesting, so much talk on this list about threadlocals, but they threadlocals seem to be used by many implementations/software out there. Not naming any names. :) > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRbDQhAAoJEBzwKT+lPKRY2voP/RejVzXwT9q3Bpq8C85sdmaU > rf4l8aSAeHY9iZDuU27dGIPYcM8eD503UFdLxNrLQmsAnIGgecxcybSzTCIaA8Q1 > kqtA58KOOkSwjWzSzyLhr7glDELXlB7BW1wiKuclrSE99NLmLQIwt5osvjv6qYxi > jPTU0y1LEKs9mXFjCmwpdjxryttMOPL+3NMjYy0PrauwxtWR1uPS3r+1bhkjtbSs > srx4aV98bFso7NydTPrbGahOHRnY1s7deNq1AzcaYsKV0ASky5cgagmk9qRyfxMd > UBAo4+cxQG2V9ccGO4PR+cuL6JQuLhfxexneFfR+FSbFPCmM9axNBexqi73BL79q > 1aOffzSKLc9gS1I7MjXgMwc20K+bDYmnWOsePAJpCIt9Jl3S77AKQYzBWapCXCu0 > H+vtVEjvH38fuByNtNTBOonqztw7EFuOAMJWg1vRzWfZyeXSljewdLjw/+jTJYNA > iULuGit9BTfIVwT2jaGfVmjebwy47GqaaisK+BF9/gLAGsG9/sSpfnYPOkjGpAZu > 1+5nYnGzx8rqlgdPOmxh0MJiJdbLeg7yJxuFnCTe5X7i4wE7jUUkBGmqnWroiYD0 > iCxWU81XQMeJDob6WMw2Cori8ZUHt/oBGz3p33ip/NzPihQrlLqqIIx3zYwpM4vt > H6hYuvJ+/t8PHKDhHR+K > =guqf > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
