ipf
ipf copied to clipboard
krasserm
Migrate FM persistence to Spring Data
If FM's persistence is using SpringData, it would be a deployment issue what kind of DB is being used (relational or not).
On the next step, we could combine some parts of the prototype implementation from Jens and the current one and make a real outstanding product for high reliable messaging.
Interesting idea but how do you ensure same lock semantics across DB implementations? I did a lot of research and debugging to get instance-level locking right and performance in Derby. You're on your way to hell!
Generally, such issues like locking should be addressed by the stack below Spring Data integration (understand combination of driver, DB and JPA implementation). As to Derby, the "right" instance locking in Derby is implemented "right" by the Hibernate Derby driver version 3.5+ combined with the Derby version that supports such locking.
Sure, that's the way to go but what if the underlying database doesn't support the locking protocol used by the FM manager such as lock upgrades, for example? Or what if the database implements lock upgrades with table locks? In this case say hello to deadlocks under heavy load. Make sure you do extensive concurrency tests when working on this.
Are you planning to make an extension here or a replacement of the existing persistence impl?
Currently I have no idea what will be essential for the design, I have to read some more about non-relational DBs. I will let you know what are my considerations if I get that further. You are right, whatever gets implemented has to be load-tested to validate the design.
I don't plan to do anything yet, it is just an idea that seems to be useful. I think the first thing to do in this direction would be to find out if the hibernate specific stuff could be dropped, so that only the JPA api is in use.