1

I have a web application which has the UI having its requests handles by Struts Action class.

Lets say that the UI sends data for 30 variables at a single request. The action class process the request and stores the 30 variables in a java object.

I need to persist the data beyond the request scope (even after the server sends response back to client for that request received, the data has to be persisted), because i have another servlet which relies on this persisted data (those 30 variables updated through UI).

Ways to persistence:

  1. Store it in DB
  2. Use JPA
  3. Use static variables.
  4. Using MQ

Which among the above would you prefer? I guess the third option doesn't hold good.

Added Points to have a better clarity:

  • The UI sends a request (holds around 30 String variable data) for every 1 minute. For every one min, the persisted data has to be modified.

  • The another servlet which relies on this persisted data is no way
    related to the request, hence i believe the session context will not be shared.

Viswa
  • 1,357
  • 3
  • 18
  • 30
  • 1
    Don't use static variables – Jim Garrison May 06 '13 at 21:13
  • It will depend on your requirements to know where to store the data. You can even pass all the data in request attributes and no need of database interaction nor HTTP session (ab)use. – Luiggi Mendoza May 06 '13 at 21:21
  • @LuiggiMendoza Out of curiosity, what's the downside of HTTP sessions? – austin May 06 '13 at 21:24
  • I forget to add few more points, pls refer the edited one at last paragraph – Viswa May 06 '13 at 21:28
  • @austin this is well explained [here](http://stackoverflow.com/q/2145945/1065197) – Luiggi Mendoza May 06 '13 at 21:32
  • Session context is shared among the same session, multiple requests can share the same session. – Luiggi Mendoza May 06 '13 at 21:33
  • @Luiggi Mendoza - Thanks for ur link. Whatz ur thought on JPA, since the data to be persisted is more – Viswa May 06 '13 at 22:01
  • @user149535 as explained in the link, it will heavily depend on how long the data must live, so if your data must live for few secs (like 30 or 300) then HTTP Session can do the work, or even better use a cache library like ehcache or infinispan. Again, you must understand that 2 servlet requests can share the same HTTP Session, and it is not discouraged (30 `String`s in session is still few data) but you must understand the risk of it and properly clean it after using the attributes. More about HttpRequest and HttpSession: http://stackoverflow.com/q/3106452/1065197 – Luiggi Mendoza May 06 '13 at 22:45

2 Answers2

2

Could you use an HttpSession? You can put the data in a session, which keeps it stored on the server side, and then it's persisted across requests and available to other servlets.

austin
  • 5,816
  • 2
  • 32
  • 40
  • Are you answering a question with another question? – Luiggi Mendoza May 06 '13 at 21:11
  • Are you commenting something or asking yet another question?, sorry couldn't resist, but by the way, I always have thought, that storing data in session is a bad idea when abusing it – jsedano May 06 '13 at 21:12
  • Wasn't one of the 4 options, so I thought maybe it was already considered. – austin May 06 '13 at 21:13
  • @anakata I asked a question about a question that could be an answer instead of a question of a question. And I agree with you, abuse of HttpSession is a bad idea. Still, it depends on the non-functional requirements to provide a solution. – Luiggi Mendoza May 06 '13 at 21:18
  • Thanks, as mentioned, i had already considered session option, which was not working. – Viswa May 06 '13 at 21:28
  • I forget to add few more points, pls refer the edited one at last paragraph – Viswa May 06 '13 at 21:29
1

Not enough information. It really depends on many different factors (what the app does, how much data, etc) which you haven't elaborated on. All of those approaches could be the correct one in a certain situation. Even the static variable option could be right in some bizarre case.

Alvin Thompson
  • 5,388
  • 3
  • 26
  • 39
  • +1 Of course!, like when you need to share the same data between various clients, then you could think of static variables, then again I feel database is the more secure one. – jsedano May 06 '13 at 21:18
  • A static variable **is never** the best solution on multi threaded environments. – Luiggi Mendoza May 06 '13 at 21:19
  • A very well synchronized singleton ... I know is an anti pattern... but sometimes it works – jsedano May 06 '13 at 21:25