2 Replies Latest reply on Nov 12, 2003 2:21 AM by jdijkmeijer

    Attempt to get lock ref with a null object

    jdijkmeijer Newbie

      Hi all I did some googling however to no avail, In a "same question" I found a reference to faq, but I never found the faq. And the answer is talking about generated db keys, which I believe is not the issue.
      So I'm questioning again (even crossposting on sourceforge) hoping no one takes offense.
      Any way point is this:
      I create in a session bean an instance of a cmp entity bean (using the localhome interface) Which goes really well. I get back a Local interface, and on this local interface I call setAnotherProperty(). At this point I get the error below. And no trace in the db of the created record, However when I comment out the last (setAnotherProperty) all works well again, obviously with a null value in the db?
      What goes wrong or where am I wrong?

      tia,
      Jroen

      2003-11-02 22:15:49,961 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy:
      java.lang.IllegalArgumentException: Attempt to get lock ref with a null object
      at org.jboss.ejb.BeanLockManager.getLock(BeanLockManager.java:80)
      at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:81)
      at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:53)
      at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
      at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243)
      at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)
      at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117)
      at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
      at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
      at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:483)
      at org.jboss.ejb.Container.invoke(Container.java:674)
      at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:353)
      at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
      at $Proxy227.setInfo(Unknown Source)

        • 1. Re: Attempt to get lock ref with a null object
          jdijkmeijer Newbie

          Yeah I found it..
          I use auto increment fields in mysql. So I create an ejb in cmp, the cmp creates a record in db and everybody is happy, right? Not everybody, as soon as you do some modification on the newly created bean the pk is still missing in the bean. The cmp is not loading the db pk in and so this is still null. Hence the error messag.
          Solutions:
          http://www.kylev.com/projects/jboss/cmpauto.html
          with xdoclet the link above can be summarized as:
          * @jboss.unknown-pk
          * sql-type="INTEGER"
          * jdbc-type="INTEGER"
          * auto-increment="true"
          * class="Integer"
          * column-name="roleid"
          * field-name="roleId"
          * readonly="true"
          * @jboss.entity-command
          * name="mysql-get-generated-keys"

          I think this is platform and db dependent. So in terms of portability maybe not the wisest choice.

          solution 2 get rid of the autoincrement fields in db design, make an extra db table, with entity beannames and generate keys and whenever you do a create call this cmp (via a session or local and retrieve the value + 1), and have the db update the key for the corresponding value. DB and appserver independent.
          I hope that both methods are cluster and thread save.
          jeroen

          • 2. Re: Attempt to get lock ref with a null object
            jdijkmeijer Newbie

            In fact the auto-gen-key option is not working..
            After creation retrieval of the pk-field results in a class cast exception. java.lang.Long vs java.lang.Integer (as it is supposed to be). I havent been able to figure why this went wrong: The field representing the pk field goes nuts after querying, so the only thing remaining is this keygen table.