I recently posted a question here: Methods to share memory or state across JVMs? and appreciate the answers. However, as I read the code and learned the system better I learned I was over complicating the problem. Only one of the JVM’s really care about the dynamic data so there is no need to pass dynamic data across memory boundries. However, we still have a problem that they are manually maintaining state between in-memory and sql; the manual code isn’t perfect and doesn’t protect against stale data, data races, etc etc and I want to remove it entirely one way or another so I can feel more secure about the overal stability.
Since only one JVM cares about dynamic data, and the dynamic data can be regenerated at bootup each time (with a small time penalty to do so) my inclination is to remove all the dynamic data from sql and just store everything in memory; why over complicate anything?
Howver, they liked the sql as a debugging tool. This system is developed agile, it’s on a live system but bugs and errors do come up due to the agile nature. When that happens they ssh to the live system and debug it on the fly; often by viewing the database. The SQL allows them to see the actual routes and pathing that are being used. They can also see when a route looks wrong, change it, then restart the module so that the fixed path is loaded into memory and used from then on. They like this ability to quickly fix bad routes don’t want to lose it.
There is now talk of keeping the database but backing it with hybernate to avoid the nightmare of trying to keep JVM and sql sychronized manually. There are some minor other gaines, but this is primarily so they can keep the sql and try to use it as a debug tool.
Something feels wrong about all of this, but I’m not entierly certain WHAT is so wrong about it. If we droped the dynamic sql data I could partially emulate what they want by adding messages to print out the graph as it is, or to modify a graph on the fly, but obviously each message takes a bit of time to write. Does keeping SQL rather then trying to write messages to allow changing of memory on the fly make sense?
I think using hibernate may make it a little harder to write our objects we use for generating and maintaining paths, having to keep the structor similar to a SQL database and all. But I think my real issue is the idea of pushing changes to our in-memory state by changing our database. That just feels dangerous to me; in much the same way improper encapsulation feels wrong. I don’t think I like the idea of fixing a broken route by just manually changing the route in sql feels safe. But I don’t know how to articulate why this all feels wrong. Maybe I should be suggesting a better debugging solution?
So, am i right to worry or is hibernate really the best approch?
What problems are you seeing in keeping your dynamic data in sync with the database?
The main benefit of Hibernate, being an object-relational mapping tool (ORM) is simplifying the mapping of rows in your database into domain objects. It does track the state of objects that were loaded from the database and can simplify committing those changes, but you’ll still need to poll the database if you need to react to changes made there. In other words, I’m not sure how Hibernate is going to help with your problem, if I understand it correctly.
It sounds like your main concern is what happens if the data in memory gets out of sync with the database. Having a separate repository for the data does introduce that possibility, so another way to gain access to the in-memory state for debugging and corrections is to expose it through JMX MBeans; see the oracle docs for details. This would mean that the data only lives inside your running application, your developers could query the JMX interface to get the current state as needed, and when changes are made to an MBean, it could trigger system events (e.g. reloading a module) as needed.
By the way, the agile nature of your project’s development doesn’t cause bugs and errors to come up; they can be found in every software project.