Home/ Questions/Q 7818007
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T06:25:42+00:00

I’m using playframework 1.2.4, and mysql database. I have some tables that are in

  • 0

I’m using playframework 1.2.4, and mysql database.

I have some tables that are in the DB, but are quite static. It is about 100-300 records of 4-7 keys.
I want to move them out of the DB.

In such cases, what would be the best place to store the information?

  • A new play configuration file?
  • XML of some-sort with a parser?
  • JSON/YAML file with access (that id don’t know it of 🙂 ) from playframework/java?
  • Java file that stores all the info in a class?

What’s the best solution and what does playframework preach for in such cases?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would group your options into the following:

    1. Relational Database
    2. XML or JSON (whether that’s a config file or some separate document).
    3. External in-memory caching such as Memcached (also available from within Play).
    4. Store the data as a Java data object, or use Play’s simple, non-distributed cache, which stores the data in the Java heap.

    You have two issues with which you’ll need to deal here: 1.) the performance of accessing your data, and 2.) the maintainability of your dataset. We can deal with these separately.

    Performance

    You have two considerations regarding performance. The first is access/lag time, the second is the amount of data stored in memory. Regarding the access time, the database will certainly have the most lag. Numbers 2 and 3 will vary depending on your hardware and OS — you’ll need to do some testing in your particular setup to really know for sure which is going to perform best. Having to retrieve the XML/JSON file from disk would certainly be much slower than accessing it from an in-memory cache, but Operating Systems are typically pretty intelligent about keeping frequently accessed files available in memory, too. It may be that the overhead of using a caching system ends up being slower than just using a static file.

    Your data will ultimately need to become a Java object in order for you to interact with it from your code. Thus, #1,2, and 3 will all require some serialization of external data into a Java object, which will take some amount of time. Accessing a Java variable (#4) will be the fastest, as it requires no extra serialization.

    Regarding the amount of data stored in memory, #2 and #4 will require that you store the entire dataset in memory each time you run the code (i.e. load any of the relevant pages). This may not be a huge concern for 7 x 300 values (8kB, if they were all floats), but when you’re expecting a single server to serve thousands of clients, that extra memory consumption used on every page load may actually become the bottle-neck for you application. You could alleviate this cost if you were able to store the data statically. Option #3 will only store the data in memory once, then shares that across all requests, which shouldn’t be a big memory penalty. #1 will likely function like #3 (at worst), in that it will store one copy in memory globally. These methods will store one global copy of the data in memory, then only serialize the relevant code into Java objects (perhaps one row of the dataset).

    Finally, note that the downside to using Play’s internal, Java-based cache is that it costs you scalability. Be sure to read the details here.

    Maintenance

    The other concern is how difficult it will be for you to maintain the data. It sounds like you’re opposed to an RDBMS-based solution because of maintenance and deployment concerns. Memcached would probably not offer you much over a database, as you would still need to ensure consistency of the cache across your deployment environments. At that point, you’re left with options #2 and #4. In my mind, it’s much easier to work with a dataset stored in XML or JSON than in Java, so I would say the benefit goes to the XML-based dataset in terms of maintainability.

    Conclusion

    So the best solution for maintenance and deployment is probably XML, the best in terms of performance would be Java-based objects. Thankfully, we can use a tool to get the best of both worlds. PojoXML allows you to convert POJOs (Java objects) to XML and back. Thus, you can maintain your data in XML, then use PojoXML to convert that document to a Java object any time you make changes to your dataset. Then you get the performance benefits of keeping your static data in compiled Java code, with the maintainability of using XML. Just be sure to store the data as a statically so that you don’t consume 8kB of memory for every page load.

    • 0