Entities with change log and database synchronisation

Question

I'm looking for a solution in the light of java, jpa2, spring, hibernate database applications that allows me to basically do something like an SCM for entities. I have a database driven java enterprise application that is hosted on multiple application servers. These application servers host stateless web applications (REST API, etc.) that are all based on the same java code and use the same database. One service this application provides is file management. Users (through various api clients and frontend applications) are able to create (upload), delete, rename, move files and folders.

Now for some time the requirement of file versions is popping up and I want to tackle this problem finally. This is what I came up with in terms of java entities:

public class File {

    private String id;
    private ReadableInstant created;

    private List<FileVersion> versions;

}

public class FileVersion {

    private String name;
    private FileVersion parent;
    private List<FileVersion> children;
    private ReadableInstant modified;
    private FileOperation operation;

}

public enum FileOperation {

    CREATE,
    RENAME,
    UPDATE,
    DELETE

}

I plan to expose File and not FileVersion directly through delegation. For this to work I need some kind of simple way to retrieve the "head" version (that would be the last entry in the versions collection). Basically every write operation on File needs to create a new FileVersion based on the then current "head". In the light of multiple application servers accessing the same database I 'm not sure if there is some way I could lock the respective File entity (row level locking?) so that I'm sure to base my new File version on the right "head".

Another thought I had would be to let the client supply some kind of version identifier his changes are based on. If at the time of persisting this version identifier doesn't match the latest FileVersion for a given File the application would have to reject the changes...

Am I going in the right direction with this or is my approach deemed to fail?

Answer 1

I would have one table which has only the "head" values (which is just like a normal table) and second table which has a journal of all the changes. This will allow you to get any previous version as well. You could create triggers to update the journal table or do it in Java.