5 Replies Latest reply on Jun 12, 2005 1:48 AM by belaban

    Two questions regarding 1.2.2 to 1.2.3

    soeren

      Hi,

      i just downloaded the new 1.2.3 version, replacing a 1.2.2 version for a project still in development. This project uses JBossCache in a standalone configuration the replicate data between a couple of clients, alias using it as a classical distributed shared memory system.

      Without changing anything at configuration or code I notice two major differences.

      1. With the old version I always got an error message like this: "ERROR org.jboss.cache.TreeCache - failed binding to JNDI as {locatorURI=socket://:5555, name=DefaultCache}, exception=Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial"

      This disappeared just in 1.2.3. As I just started with JBossCache this is something I wanted to ask anyway ,-)) But I don't know if the problem has really disappeared with 1.2.3 or just doesn't show up as an error message as I don't know what the original problem was.

      The configurtation directive (default from the jboss-archive) looks like this:

      <attribute name="JndiName">
       name=DefaultCache
       locatorURI=socket://:5555
       </attribute>


      2. I noticed a change in the locking strategy? Currently the cache uses REPEATABLE_READ (default) as IsolationLevel. I noticed that a thread, reading or writing to a node did not release locks automatically after reading/writing, leading to a fast death of the application caused by hundreds of locks. I tried to insert releaseAllLocks(node)-statements after each write but this didn't help as nothing happend at all: I just saw my processes now consuming 100% CPU (probably doing some spin-locking).

      It should be added that we don't use the transactional features using any external transaction manager of the JBossCache but want to rely completely on the built features of J.

      I finally changed the IsolationLevel to NONE and now everything works fine - although I expect some problems later on in production when we'll see heavy concurrent modifications happen.


      Best regards,
      Soeren Gerlach

        • 1. Re: Two questions regarding 1.2.2 to 1.2.3
          belaban

          In 1.2.3, running *without* transactions, we acquire the locks during a method call, and release them after the call returns.
          If your locks are not released, then this is a bug, or you're not committing your transactions. Create a reproducable unit test and a JIRA case and attach it to the JIRA case.

          • 2. Re: Two questions regarding 1.2.2 to 1.2.3
            soeren

            Hi Bela,

            "bela@jboss.com" wrote:
            In 1.2.3, running *without* transactions, we acquire the locks during a method call, and release them after the call returns.


            Sorry to ask you for this detail: Default mode (as the zip from sourceforge comes) means "REPEATABLE_READ". This just means a locking strategy but not a transaction manager involved? Or does this involve some JBossCache-built-in t.m.? I'm a little confused as it looks like for me if the use of a transcation manager and the node locking level are not linked together in any way? Coming from a database background I know there's always a transaction manager somewhere, otherwise locking is quite not possible. I need to be clear with this as to reproduce a matching case eventually for this:

            "bela@jboss.com" wrote:
            If your locks are not released, then this is a bug, or you're not committing your transactions. Create a reproducable unit test and a JIRA case and attach it to the JIRA case.


            To commit a transaction I must use a transaction manager, correct? So I assume that the use of "REPEATABLE_READ" in fact involves a JBossCache provided transaction manager BUT THEN I should use something like " tx.begin()" and "tx.end()" around each "cache.put(node)" call? This is somewhat surprising me as in 1.2.2 I just coded a "cache.put(node)" without any transaction code. So probably I've missed something so far in our coding? E.g. the very short demo code in chapter 4 of http://docs.jboss.org/jbcache/current/TreeCache/html/ also doesn't involve any transactional code.

            Currently we're using the - default setting - DummyTransactionManagerLookup as Transaction manager. Rereading the docs now it's not clear to me if this is suitable for an standalone (outside JBoss) application. We're planning to have some 6-10 clients here on different physical hosts and having REPEATABLE_READ would be nice but not necessary at all.


            Thanks,
            Soeren Gerlach


            • 3. Re: Two questions regarding 1.2.2 to 1.2.3
              belaban

              Locking can be used separately from a TxManager.

              If you have a TxManager *and* you started a TX, then all locks are held until the end of the TX.

              If you didn't start a TX, or don't have a TxManager installed, the scope of the locks is per method call

              • 4. Re: Two questions regarding 1.2.2 to 1.2.3
                soeren

                Hi Bela,

                it took me quite some hours today to find the exact problem but finally I was able to reproduce it. I have compiled everything together in JBCACHE-192.


                Best regards,
                Soeren

                • 5. Re: Two questions regarding 1.2.2 to 1.2.3
                  belaban

                  Thanks, I assigned it to 1.2.4 (next release) in JIRA.