3 Replies Latest reply on Apr 23, 2008 2:43 PM by jason.greene

    Pojo cache performance and concurrency problem

    waldekc

      Hi all

      What I want to do:
      I have several nodes in cluster, each node uses pojocache
      In pojocache under fqn there is attached a list (i.e. pojoCache.attach(fqn, new ArrayList())

      Each node uses this replicated list (List list = (List) pojoCache.find(fqn))
      and can remove (via list.remove(0)) or write (via list.add(object)) annotated object.
      Nodes can asynchronously do many writes and removes.
      And very important for me: only ONE node can get (and remove) concrete object from this replicated list.
      I use transactions.

      Here are my problems:
      1) Write dozens of objects (in one transaction) to the list causes very high server load.
      2) Is it possible to do removing described above with pojocache ? If yes, with reasonable performance ?
      I had spend some time without success, checked many pojocache configurations.
      Hints are very appreciated ;)

      Thanks
      Waldek

      My configuration
      WinXP
      JDK 1.5.0_15
      Pojocache 2.1.0 (NodeLockingScheme - Optimistic, TransactionManager - GenericTransactionManagerLookup, IsolationLevel - READ_COMMITTED, CacheMode - REPL_ASYNC)
      Jboss 4.2.2 and 5.0 with enabled load-time weaving (compile-time also checked)
      I'm also sure that pojo interceptors and annotations work fine.

        • 1. Re: Pojo cache performance and concurrency problem
          jason.greene

          If I understand you correctly, are you asking for the exact behavior of BlockingQueue? (a guarantee that only one node will ever read an entry). To do this you need a distributed lock, which we don't yet support (they usually aren't desired in a cache since it negatively impacts scalability).

          A JMS queue might fit your use-case better.

          • 2. Re: Pojo cache performance and concurrency problem
            waldekc

            Thanks

            Bad news
            Yes, JMS queue was my first choice, but it has one big limitation for me - you cannot freely modify queue (random access to messages, changing priority ..).

            Because of that I checked JbossCache
            And maybe you know any alternatives ?

            • 3. Re: Pojo cache performance and concurrency problem
              jason.greene

              You could do this with any kind of shared data source that supports global lock acquisition. You could use an RDBMS that supports "select for update" for example. You could also build a simple communication layer over your own data structure (that locks appropriately), or something like BDB, if you want persistence. It's fairly easy to do this with jgroups. You might be able to extend the jgroups DistributedQueue example to do what you want, although it was designed around the idea of a lot of local non-mutating reads, which i am guessing doesn't match your case.

              We do have selective distributed locking on the roadmap (for specialized cases like this), but there are some higher priority features like partitioning and mvcc that we are focusing on atm. Sorry I am not much help here.