Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 0.7
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      independant

      Description

      I could not find an in-memory DataModel that supports setPreference / removePreference / refresh. Instead, they all "recreate" a new GenericDataModel anytime one adds or remove preferences.

      1. MutableDataModel.java
        11 kB
        Renaud Richardet

        Activity

        Renaud Richardet created issue -
        Renaud Richardet made changes -
        Field Original Value New Value
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        Renaud Richardet added a comment -

        Implementation, based on GenericDataModel

        Show
        Renaud Richardet added a comment - Implementation, based on GenericDataModel
        Renaud Richardet made changes -
        Attachment MutableDataModel.java [ 12539199 ]
        Renaud Richardet made changes -
        Comment [ Implementation, based on GenericDataModel ]
        Hide
        Sebastian Schelter added a comment -

        Hi Renaud,

        I really like the idea of having a mutable in-memory datamodel. I think however that such an implementation should be threadsafe and I don't think that this is already the case with your implementation.

        What do you think? Could you enhance the patch to make the model threadsafe?

        Btw: Your patch doesn't adhere to Mahout style guidelines and Apache doesn't allow @author tags.

        Show
        Sebastian Schelter added a comment - Hi Renaud, I really like the idea of having a mutable in-memory datamodel. I think however that such an implementation should be threadsafe and I don't think that this is already the case with your implementation. What do you think? Could you enhance the patch to make the model threadsafe? Btw: Your patch doesn't adhere to Mahout style guidelines and Apache doesn't allow @author tags.
        Hide
        Renaud Richardet added a comment -

        Hi Sebastian,

        > Could you enhance the patch to make the model threadsafe?

        Sounds good. Shall I use import util.concurrent.locks.ReentrantLock like in MongoDBDataModel?

        > Btw: Your patch doesn't adhere to Mahout style guidelines and Apache doesn't allow @author tags.

        Ok, will change that.

        Show
        Renaud Richardet added a comment - Hi Sebastian, > Could you enhance the patch to make the model threadsafe? Sounds good. Shall I use import util.concurrent.locks.ReentrantLock like in MongoDBDataModel? > Btw: Your patch doesn't adhere to Mahout style guidelines and Apache doesn't allow @author tags. Ok, will change that.
        Hide
        Sebastian Schelter added a comment -

        Hi Renaud,

        I think its much more complicated then using a lock. In the current non-mutable DataModels, we simply rebuild the underlying datastructure and switch it in refresh(). In a really mutable case however, we would have to support concurrent updates and would also have to ensure that readers still get a consistent view of the data.

        Show
        Sebastian Schelter added a comment - Hi Renaud, I think its much more complicated then using a lock. In the current non-mutable DataModels, we simply rebuild the underlying datastructure and switch it in refresh(). In a really mutable case however, we would have to support concurrent updates and would also have to ensure that readers still get a consistent view of the data.
        Hide
        Sean Owen added a comment -

        In my view the only essential condition is avoiding corrupting data structures or exceptions due to concurrent modification. It is OK for a request to see an update partly completed, or a reload not yet finished, I think. Reads should be able to proceed concurrently, so some kind of ReadWriteLock is probably needed. Beyond that, overly coarse synchronization (i.e. one lock for the whole class) feels OK to me.

        Show
        Sean Owen added a comment - In my view the only essential condition is avoiding corrupting data structures or exceptions due to concurrent modification. It is OK for a request to see an update partly completed, or a reload not yet finished, I think. Reads should be able to proceed concurrently, so some kind of ReadWriteLock is probably needed. Beyond that, overly coarse synchronization (i.e. one lock for the whole class) feels OK to me.
        Sean Owen made changes -
        Fix Version/s 0.7 [ 12319261 ]
        Sean Owen made changes -
        Assignee Sean Owen [ srowen ]
        Sebastian Schelter made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Resolution Won't Fix [ 2 ]
        Suneel Marthi made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Renaud Richardet
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development