2 Replies Latest reply on Dec 28, 2009 5:33 PM by Brandon Simpson

    Hibernate versioning in the real world

    Brandon Simpson Newbie

      I understand the basic idea of versioning, but I haven't yet seen a real world example of how to handle it. Here's the situation I'd like to find a solution for:


      I want users to be able to enter content/data and edit this content/data at will. I'd also like for administrators to be able to edit the users' content/data if needed and for this content/data to be approved by the administrators before appearing live on the website.


      I'm concerned about the case where the user is making some changes to their content/data, and while doing this, an administrator updates the same entity advancing the version. Then once the user submits, a versioning collision is going to be detected, and the user will get an error message or something like that potentially losing their edits.


      From what I've read, it sounds like if you have a versioning collision, you need to throw away the persistance context and create a new one. (How would you do this anyway? Null out the entityManager? Does Seam handle this correctly and transactions, etc. will be ok?)


      Additionally, this seems to open up additional problems. For example, if you do things the Seam way and use a persistance context in a long running conversation, that's where the state of the user's data/content is stored, so if I don't make some sort of copy, I'm going to lose the user's data/content even though they haven't done anything wrong or entered any invalid data (just because of timing and an intermediate update by an administrator on the same or related data). To me that would be an unacceptably bad user experience.


      Anyway, I've read several times about versioning and how you can handle collisions (i.e. prompt the user whether to work with new data or force their changes to be saved), but I've seen no real examples on how to actually do it. But additionally, how can I handle a case like mine, where I don't want to lose the user's data/content and really don't even want them to know that there was a collision?


      So far it seems like the very hardest part of versioning is just left up to the user to deal with. I'm starting to question whether or not it's a good idea to do any editing that directly affects a persistance context at all since it seems to cascade into all sorts of problems. This seems sort of contrary to the ideas behind Seam if I'm not mistaken...that you can work directly with entities in the view and in the persistence context and not have to write all the glue code to move data between them.


      I'd love to hear some thoughts on this. I've written some similar questions in the past but typically gotten litter or not responses. I'm not sure if I'm just not effectively explaining what I perceive the problems to be, if no one is writing complex webapps, if no one has a good solution, or what!

        • 1. Re: Hibernate versioning in the real world
          Ilya Dyoshin Novice

          Good day.


          In your case I'd suggested to use the Pessimistick locking not the Optimistick locking which is provided via @Version annotation.


          Simply create some facade for your objects and create some storage for object currently edited - and in the facade simply deny acces to objects which are currently edited by other users (administrators).


          If your data would be edited so frequently the pessimistick locking is the only one solution for you.


          However  you can create the workflows on your objects and rules on prooving the changes - in this case you need to overthink your database structure and the whole applicaiton.


          I've been working with such problem heavily and used both solutions in the same application, depnding on data change frequency.


          Regards!


          Ilya Dyoshin

          • 2. Re: Hibernate versioning in the real world
            Brandon Simpson Newbie

            Thanks, Ilya! So far I have been handling this primarily through careful database structuring to avoid conflicts. I'll have to think about the pessimistic locking some more. Thanks again for taking the time to respond!