[Last Call] Learn about multicloud storage options and how to improve your company's cloud strategy. Register Now


Java web app class/database design philosophy

Posted on 2007-11-15
Medium Priority
Last Modified: 2011-09-20

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!

Question by:courtenayt
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
LVL 27

Accepted Solution

mrcoffee365 earned 2000 total points
ID: 20291610
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.

Author Comment

ID: 20350297
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?
LVL 27

Expert Comment

ID: 20350983
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.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.


Author Comment

ID: 20459862
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 :)
LVL 27

Expert Comment

ID: 20459926
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!

Author Comment

ID: 20459967
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!


Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Recently I was talking with Tim Sharp, one of my colleagues from our Technical Account Manager team about MongoDB’s scalability. While doing some quick training with some of the Percona team, Tim brought something to my attention...
In this blog post, we’ll look at how ClickHouse performs in a general analytical workload using the star schema benchmark test.
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…
This is a high-level webinar that covers the history of enterprise open source database use. It addresses both the advantages companies see in using open source database technologies, as well as the fears and reservations they might have. In this…
Suggested Courses

650 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question