CODEWITHSUNDEEP
javaspringspring-mvcredux
erik-sn
erik-sn

Reputation: 2600

Global State in Java/Spring

I have a basic Java/Spring MVC CRUD application in production on my company's intranet. I am still a beginner really, this application is what I've used to learn Java and web applications. Basically it has a table that uses AJAX to refresh its data on regular intervals, and an html form that is input into the database. The refresh is important because the data is viewed on multiple computers that need to see the input from the others.

The problem is that, due to network issues outside of my control, the database transactions on certain computers can be very slow.

I have been playing around with React/Redux JavaScript client applications in the past few weeks and the concept of state. Now, as best I can tell, global state or variables are pretty reviled by the Java community. Bugs, difficulty in testing, etc.

But Redux gave me an idea that, when a user hits "submit" instead of inserting a row into SQL, it stores that object in memory on the server. Then at regular intervals that memory is inserted into the database - so the user does not have to wait for database transactions, only communication with the server. Table refreshes don't look at the database - they look at this memory.

But, again as a beginner, I don't see people do this. Why is it a bad idea?

Upvotes: 1

Views: 1003

Answers (1)

rmalchow
rmalchow

Reputation: 2769

In general, it isn't done for two reasons:

  • the state is not guaranteed, because it is not actually written. If you restart the application before the data is flushed to the database, it is silently dropped. This is not a good thing in general, although obviously, but your interpretation may very. If you don't care so much, this might be ok. You could remedy this by persisting it somewhere locally.

  • the state is also not guaranteed, because you may end up not being able to write the data because, for example, some database constraint.

So, in general it is frowned upon, because you are lying to the client ... You say you wrote it, but there's no actual effort to ensure this has actually happened.

But then again. if the data is less important, it might be ok.

Upvotes: 1

Related Questions