Design Problem


General J2EE: Design Problem

  1. Design Problem (3 messages)

    The problem: In the application i am developing now, the requirement is to archive all the data changes made by the user which are not yet persisted to the database. For eg, i have add/update/delete actions on a page and these changes not supposed to be saved to their respective tables unless user hits 'Save All' button. And if user leaves the page without hitting Save all button, i need to keep them somewhere so i can give an option to the user to save them or discard them at any point of time. The options i have are 1) Keeping these changes in the memory. This can be resource taxing depending the amount of changes in the application. For eg if there are 100s of records have been updated or mass changed, we may be talking about lot of data in the memory. And what if user closes the browser intentionally or otherwise, he will lose all the changes. 2) Keep these changes in the database. For eg, for every action on the application like add/delete/update, the data will be updated in the memory as well as in a temporary table in the database, along the lines of transaction and rollback. This way even if user leaves the browser without saving them, we have an option of showing them in the screen, next time they login. I am leaning towards option 2 using a JMS Pipe to send every actions to the database. Please suggest if there is any pattern i could use or how best this can be solved. Thanks

    Threaded Messages (3)

  2. Trade Off[ Go to top ]

    Well! your requirements seems that: 1: you want to persist the data even if the user closes the browser and want to show them again even if they login say 1 week later. 2: You are not very confident in storing them in memory because you are very memory aware. If you want to show them after a week, you need to keep them somewhere.Permanent storage is the only option. Now we can get that as: 1: store data in xml files, if your data is large, memory will be a issue. 2: store them in a different database,here you need two databases. The solution is listener pattern, when ever the user makes some actions, the listeners will be notified, if the user does not perform "save all", the listener will not commit the data to the main database, if the user closes the browser, the listener will keep the data for the user with it, next time save all will make it commit.Now you can implement it not only through JMS but also through simple java classes acting as you listeners. If i could not make myself clear, please let me know, cheers,
  3. Re: Design Problem[ Go to top ]

    I would surely go for option# 2. Its not just about the size of objects in the runtime-memory, you need to display the data to the user even if the server has been re-started. So saving the data in a persistence store is the option. But... have you thought about cleaning up of the data if a user does not login for quite some time? We too have a similiar kind of requirement. We have an import data to db functionality. I this process if the session times out or browser is closed then we need to display the result nexttime user logs-in. Krishna
  4. Re: Design Problem[ Go to top ]

    Thanks for the replies folks. Yes, I will go with option 2 as well as it is more flexible. Regarding cleaning up the data, we need to get the requirements from our users. This is still in its infant stage. Hopefully we can suggest to clean it up in specified number of days or something along that lines.