11 Replies Latest reply on Apr 24, 2007 11:25 PM by darose

    Node locking question

    darose

      Hi. I'm kicking the tires on integrating JBossCache (2.0beta) into an app of mine. So far looks pretty good, but I've run into one small snag.

      I would like to find a way to atomically replace the contents of a node - i.e., perform:

      node.clearData()

      followed by

      node.putAll(map)

      all while the node is being locked.

      In other words, a method something like:

      node.setData(map)

      if it existed.


      From what I can glean from the (somewhat minimal) details in the docs about locking, it looks like the putAll method operates under a lock, which is somewhat helpful. But the problem with using that is that if the old map contained mappings that don't exist in the new one, the old mappings will still remain in the node's data.

      So what I'm looking for is a way to replace the node's entire data. Any thread-safe way to do that?

      TIA,

      DR

        • 1. Re: Node locking question
          genman

          There used to be a Node.putAll(Map map, boolean erase) method.

          The thread safe way (at the moment) is to use a transaction.

          • 2. Re: Node locking question
            darose

             

            "genman" wrote:
            There used to be a Node.putAll(Map map, boolean erase) method.

            The thread safe way (at the moment) is to use a transaction.


            But ... I thought that transactioning was automatic and completely hidden away from the user. Is that incorrect? If so, how would I go about wrapping a transaction around my calls to clearData() and putAll()?

            • 3. Re: Node locking question
              genman
              • 4. Re: Node locking question
                darose

                What about in 2.0 beta? I didn't seem that say passage in the 2.0 documents.

                Plus, the doc is a bit vague. Seems like I'm supposed to use one if I'm using the JBoss app server (which I'm not), and use the dummy one if I'm using JBoss cache standalone (which I am) - except that the dummy one is not meant for production use?!?!?!?

                I have to say, explicit transactioning seems a bit kludgey here.

                Can anyone explain a bit more clearly what it is I'm supposed to do here to over-write a node's data atomically?

                • 5. Re: Node locking question
                  genman


                  Although there could easily be an API for handling atomic data clear/put, there is none and will be none for many other similar situations, such as bulk put or bulk remove. So, your best bet is to learn to like transactions.

                  Manik s. (who often haunts these forums) came up with the documentation.

                  I would say the DummyTransactionManager is suitable for these sorts of things, so I don't see why it's not production ready. Certainly, it would not be suitable for distributed transaction cases or durable transaction processing. And so the DummyTransactionManager really should be renamed. Maybe it should be called the "MemoryTM" or "NonDurableTM" as it does confuse users.

                  I'll file an issue to clarify this.

                  • 6. Re: Node locking question
                    genman
                    • 7. Re: Node locking question
                      darose

                       

                      "genman" wrote:

                      Although there could easily be an API for handling atomic data clear/put, there is none and will be none for many other similar situations, such as bulk put or bulk remove. So, your best bet is to learn to like transactions.



                      "genman" wrote:
                      I would say the DummyTransactionManager is suitable for these sorts of things, so I don't see why it's not production ready. Certainly, it would not be suitable for distributed transaction cases or durable transaction processing. And so the DummyTransactionManager really should be renamed. Maybe it should be called the "MemoryTM" or "NonDurableTM" as it does confuse users.

                      I'll file an issue to clarify this.


                      OK, I'll use that, then. Thanks much for the clarification and filing the issue.

                      • 8. Re: Node locking question
                        brian.stansberry

                        The differently named version already exists -- see http://wiki.jboss.org/wiki/Wiki.jsp?page=BatchModeTransactionManager.

                        DummyTransactionManager is a unit testing tool, and one of the things it does is when you retrieve the singleton instance, it registers itself in JNDI as java:/TransactionManager. Not likely something you want it to do in a production system.

                        • 9. Re: Node locking question
                          genman

                          I forgot about that JNDI bind part. Any reason why unit tests don't use BatchModeTransactionManager instead?

                          • 10. Re: Node locking question
                            brian.stansberry

                            Probably no good reason; i.e. BatchModeTransactionManager is relatively newer so the habit was to use Dummy.

                            • 11. Re: Node locking question
                              darose

                              Can someone please confirm:

                              Would this then the correct usage of BatchModeTransactionManager in the context I mentioned?

                              BatchModeTransactionManager txMgr = BatchModeTransactionManager.getInstance();
                              txMgr.begin();
                              child.clearData();
                              child.putAll(recordVals.getValues());
                              txMgr.commit();