• Post Reply Bookmark Topic Watch Topic
  • New Topic

'singleton objects' to coordinate read/write

 
marten kay
Ranch Hand
Posts: 188
Java jQuery Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am developing a little web application where each session will have access to a large number of documents shared in the app. The documents are immutable and their object representations are immutable.

To minimize and control the number of documents in memory, I have created a singleton DocBank that has a map of all documents in memory.

To synchronize reading the documents into memory, and to not lock the DocBank for I/O, the DocBank map contains simple DocIoManager(s) with each manager containing a reference to its Doc.

The DocIoManager is then responsible for synchronized reading (and writing) of the document from disk when it is called the first time.

The client then, to get a Doc, does something like this

Doc doc = DocBank.getInstance().getDocIoManager(1).getDoc();


My Code is below.

Am I doing something stupid or anti-pattern? I have looked extensively through Goetz's Concurrency in practice and can't quite find a scenario that matches mine, but maybe I'm not getting it.

Any advice would be appreciated.

Thanks

(am also using WeakHashMap, so that when no more sessions reference the doc, the manager gets collected for garbage)



[ November 15, 2008: Message edited by: marten kay ]
[ November 15, 2008: Message edited by: marten kay ]
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I get, you have two requirements:
  • Read any doc only once in memory.
  • Synchronize read-write to the document.


  • Based on these requirements, your design looks correct apart from the fact that the existence of DocIOManager sounds a little different to me.
    Ideally, if I am a user of this api, I would like the write/read methods to be available on the Doc object itself.
    Going through an indirection (IOManager) to write the document is a little too much.
    You can probably provide a write method on the Doc itself which can be synchronized.
    In order to improve concurrent reads performance you can probably use a ReadWriteLock

    As for your current implementation, it is not really thread-safe as you are making the Doc object "escape" from the I/O manager and thus it will be difficult to synchronize reads and writes for the Doc object. What I mean is someone can be reading state from the Doc object even when IOManager write is in progress. (Unless ofcourse you synchronize all reads of Doc object on the IOManager instance)
     
    marten kay
    Ranch Hand
    Posts: 188
    Java jQuery Postgres Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Nitesh,

    Thank you so much, for both your full understanding of my situation and your advice.

    By way of clarification, escaping of the Doc object is OK because the object is immutable. The write functionality is provided for when the object is created, that is, when data received from the web-client data is used to create the Doc in memory as well as write it to disk. But this could be cleaned up I agree.

    Also, a Doc could be made up of many other Docs so, along with meta files, the building of a Doc is a detailed process that I have factored from the Constructor of the Doc, but maybe this is a bad idea.

    So I am wondering if it is a good idea to to have multiple reads inside the Constructor of Doc object, or if this needs to be factored out in a builder.

    I will ponder this a bit. But again, thanks for advice, I am on my way.

    Cheers

    Marten
     
    Don't get me started about those stupid light bulbs.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!