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?