• Post Reply Bookmark Topic Watch Topic
  • New Topic

caching often used data  RSS feed

 
Jim Henessey
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have an app which pulls data from an XML file, places it in arrays and then does heavy sorting/re-distribution of the data given various specs. My question is:

Is there anything out there in java I can use to store my array data, so I can avoid having to pass the array data around from object to object? The alternative to this would be to keep pulling the data from the XML file and doing the re-distribution each time, which is just too damn expensive.

If the above explanation of the problem isn't sufficiently clear, let me know and I'll try for greater precision.

Thanks for the help - java ranch has been invaluable for learning and improving my java skills.
 
Mike Gershman
Ranch Hand
Posts: 1272
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you mean caching in terms of too much data to all fit in memory, weak references help you use all available memory without accidentally running out.

If not, why do you have a problem keeping your array in memory?
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Henessey:
Is there anything out there in java I can use to store my array data, so I can avoid having to pass the array data around from object to object?
There are three other ways I can think of immediately to keep the arrays in memory. Note that the key factor is that you need to be able to obtain the array references to use the arrays, so it's a matter of where you put those references.
  • Store them in each object that will use them. This would make sense if the objects operating on the arrays are created once (along with the arrays) and then reused. Of course, now you need to keep references to the objects.
  • Store them in static fields of an "ArrayCache" class. Easy, but limits future changes -- say you need to proces multiple sets of arrays.
  • Create a ThreadLocal to hold them for your main thread, assuming you are using only one thread to process the arrays.

  • Just to be clear with respect to the first option, storing multiple references to the same object doesn't duplicate the objects -- just the references (4 bytes each), so making them instance members of the processing classes adds little overhead.
     
    Stan James
    (instanceof Sidekick)
    Ranch Hand
    Posts: 8791
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Why is "pass the array data around from object to object" a problem? Passing a parameter to another method just passes a very small pointer, not a copy of the whole array, so it's very efficient.

    We might be concerned if too many classes know about the array and have their fingers in manipulating it. Changing the array in some future release could break a lot of classes and if we later find corrupt data in the array we don't know where to find the guilty code. Then we might hide the array inside a new class and put all the code that manipulates the array inside that class as well. That's the goodness of "encapsulation" in OO ... putting all the code that needs to know about the array - and might be broken by a change to the array - in one place.

    Let us know if that sounds interesting.
     
    Jim Henessey
    Ranch Hand
    Posts: 32
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for all the help on this one I really appreciate it.

    Mike - I should have used a different term than "caching", which I'm misusing in this sense. I supposed a better definition of what I was looking for was objects with a persistent lifespan which immitate those objects declared outside of any class in a weaker OO language.

    David - I was considering object references / static fields in a separate class. I'll look into the thread option as well.

    Stan - I can appreciate the strengths of this approach. By limiting access to data, the programmer needs to look at only a small number of places where data might have been corrupted. I just found that I was passing around certain data parameters all over the place and was wondering if there was something I was missing here - I like to know if there's an easier approach to something early on when learning a language, rather doing things the wrong way for a few years.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!