Java web app class/database design philosophy


I'm creating a web application using JavaBeans, JSP & Postgres.  My database contains 2 major types of data 1) CMS-type data used for displaying forms & the info listed in drop-down menus, radio buttons, etc.  2) user-submitted data that is entered by users of the web-app via forms.

For all of the CMS-type data I am pulling it from the database into singleton JavaBean classes at the start of the application so that it can be accessed by the application via objects instead of making database queries.  For user-submitted data, I am submitting the data to the database for storage.

I am now working on providing users of the application with a way to view the user-submitted data.  I can see two different approaches for how to do this, and would like to get your opinion on which would be the best approach.

Approach 1) Each time someone wants to view user-submitted data, that data is pulled from the database into an instance of an object that represents the type of form data they are viewing.  Once the object is no longer in use, the garbage collector would clean it up.  More than one instance of this object could be created at once, so multiple users could have their own instance with the latest info from the database.

Approach 2) At the start of the application pull all of the user-submitted data into singleton classes each representing a different form submitted.  If a user submits a new form, then create a new object in memory with all of the form data and then (afterwards) submit that same data to the database for persistence.  If someone modified an existing form, the in-memory object would be updated first and then the database would also be updated - same for deleting an object.  This would be done to ensure that whoever was viewing an object (by accessing that object's methods) would have the most up to date information and the database would remain in the background for storage purposes only.

It seems to me that from a design perspective, approach number 2 would be the best for separating out the database from the code, but I'm worried that it may be too memory intensive.  The application will eventually have hundreds of millions of user-submitted forms, and I'm concerned that it might be a problem to hold all of those objects in memory all of the time.  None of my objects would be very large - at most 40 attributes and 99% of them would be short strings or ints.  I may occasionally have blobs for pictures or attached documents, but that is going to be rare.

Does anyone have any experience with these different approaches or any other approaches that might be better than the ones I've come up with?

If you need more information on how much memory my objects will take, please ask me specific questions as I am not as familiar with how to quantify program memory.  Also, if you think that the answer lies in the speed/performance of my hardware or load balancing, etc. could you give me details on what hardware/equipment/practices I should be using to do this?  I'm using a hosted Linux server to run my code.

I look forward to getting your input!

Who is Participating?
I highly recommend not using method 2 for your user-maintained data.  If you do not use the database as the manager of changes to your data, then you'll have to build in all of the data update management in your application.  It is extremely rare for an application to have special needs that require emulating a database on top of your database.

It is far cheaper to add machines, if you are worried about application load, than to develop all of the code to successfully manage user-maintained data without the database.

In fact, you'll have to do some work to emulate a database by making all your metadata loaded once in singleton classes.  If you do that, you'll need to make sure that you build a mechanism that updates the metadata (CMS data) when you make changes to it.  Or you can stop and start your Web server with every change to the metadata.
courtenaytAuthor Commented:
Thanks for your input.  I'm currently stopping and starting my application to pull in data for display purposes, but that is not a problem since that data is only updated when I am releasing a new version of the code to the production server and have to restart my JVM anyway.  

So it seems you feel it's more efficient and effective to always go directly insert & query from the database without using intermediate classes as described above - I'm I correct?
Yes, for data that users can modify, I think it's a better solution to always get it from the database.

For metadata, since you control when that changes, it's more up to you as to how you want to manage the process.  If there's a performance reason to reduce queries to your db, then you're right, singleton JavaBean classes will do that.  If possible, though, I prefer to get the data from the db every time, because then maintenance and upgrades are less disruptive.

On the other hand, we frequently develop apps where there are initializations of metadata with each user session, which is similar to the singleton classes method you described above.  So I've had the same situation of requiring a bounce of the Web server when a new feature is introduced which requires all accesses to initialize again.

For user data, it has to be a severe performance issue (and they do happen, sometimes) for me to be willing to build the layer to allow singletons of the data, but with checks for data modifications.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

courtenaytAuthor Commented:
Thanks for the input - I think I'm going to stick with what I've got (non-user updated data pulled into singleton classes @ startup & user updated data pulled directly from the database).  It will definitely save time since I already have it built that way :)
Saving development time is a good thing.  I think the important point is that you are aware of the behavior of your two methods, so you can manage the site successfully.  It's a very reasonable architecture and sounds as if it will do what you want it to.  Good luck!
courtenaytAuthor Commented:
Thanks so much!  It's really great to have someone to discuss these ideas with since I'm currently a one person team on a huge app - new product design is crazy sometimes!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.