-
1. Re: findByPrimaryKey and Commit Option A
juha Sep 10, 2003 2:26 AM (in response to avirokach)Which version of JBoss are you using? What does your deployment descriptor look like for the beans?
-- Juha -
2. Re: findByPrimaryKey and Commit Option A
jacyg Sep 11, 2003 5:08 PM (in response to avirokach)We have this problem too:
We are using jboss-3.2.1 with default jetty web server container, and
jdk1.4+.
We are using CMP2.0 entity beans, and accessing them from within
stateless session ejbs. Everything works fine if we use jboss's
commit option B. However, we would really like to be able to have
some sort of data cache, and were counting on JBoss to be able to do
that for us. But, when we try to use commit options A or D, the ejbs
start acting oddly....
Here's an example of what we are running up against:
try {
MyLocalIntf intf = ejbHome.findByPrimaryKey(new Long(27023));
doSomething(intf.getParentId());
} catch (FinderException fe) {
//more logic
}
Now, if the bean with a primary key of 27023 doesn't exist, you would
expect a finder exception to be thrown. However, we get this instead:
javax.ejb.NoSuchObjectLocalException: Entity not found:
primaryKey=27023
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:158)
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 $Proxy461.getParentId(Unknown Source)
These calls are being made within a stateless session bean with
transactions required. Why in the world isn't it throwing the
FinderException?? Please, if you have any familiarity with this
issue, it's been mystifying us.
Also, to address the poster who asked about deployment descriptors, here are the deployment descriptors for *one* of the beans we are having this problem with (there are others, as well, similarly structured).
******************ejb-jar.xml:
<display-name>TreeStructure</display-name>
<ejb-name>TreeStructure</ejb-name>
<local-home>com.fuelquest.tree.ejb.TreeStructureHome</local-home>
com.fuelquest.tree.ejb.TreeStructure
<ejb-class>com.fuelquest.tree.ejb.TreeStructureBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Long</prim-key-class>
False
<cmp-version>2.x</cmp-version>
<abstract-schema-name>TreeStructure</abstract-schema-name>
<cmp-field>
<field-name>objectId</field-name>
</cmp-field>
<cmp-field>
<field-name>parentId</field-name>
</cmp-field>
<cmp-field>
<field-name>pathToRoot</field-name>
</cmp-field>
<primkey-field>objectId</primkey-field>
<query-method>
<method-name>findByParent</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<ejb-ql>select object(ts) from TreeStructure ts where ts.parentId = ?1</ejb-ql>
<query-method>
<method-name>findByPath</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</query-method>
<ejb-ql>select object(ts) from TreeStructure ts where ts.pathToRoot like ?1</ejb-ql>
**************jbosscmp-jdbc.xml
<ejb-name>TreeStructure</ejb-name>
<table-name>TREE_STRUCTURE</table-name>
<cmp-field>
<field-name>objectId</field-name>
<column-name>OBJECT_ID</column-name>
</cmp-field>
<cmp-field>
<field-name>parentId</field-name>
<column-name>PARENT_ID</column-name>
</cmp-field>
<cmp-field>
<field-name>pathToRoot</field-name>
<column-name>PATH_TO_ROOT</column-name>
</cmp-field>
<query-method>
<method-name>findByParent</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<jboss-ql>select object(ts) from TreeStructure ts where ts.parentId = ?1</jboss-ql>
<query-method>
<method-name>findByPath</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</query-method>
<jboss-ql>select object(ts) from TreeStructure ts where ts.pathToRoot like ?1</jboss-ql>
***********jboss.xml
<ejb-name>TreeStructure</ejb-name>
<local-jndi-name>TreeStructure</local-jndi-name>
<method-attributes>
<method-name>get*</method-name>
<read-only>true</read-only>
</method-attributes> -
3. Re: findByPrimaryKey and Commit Option A
aloubyansky Sep 13, 2003 6:19 AM (in response to avirokach)Guys, could you give me instructions on how to reproduce it? I had no luck till now. I used JBoss-3.2.2RC3.
I think it's a good idea to submit a bug report on it. -
4. Re: findByPrimaryKey and Commit Option A
jacyg Sep 16, 2003 1:32 PM (in response to avirokach)Well, other than what I posted with my descriptors...there are two many to one unidirectional relationships between the relationships bean and the tree structure bean. One goes from the objectId to the objectId, the other from the ownerId to the objectId. Also, this happens for the id at the top of the hierarchy (in this case, the top level of the tree is not stored in the treeStructure table, so a findByPrimaryKey with the top level ID should throw a finderException)
-
5. Re: findByPrimaryKey and Commit Option A
avirokach Sep 21, 2003 5:37 AM (in response to avirokach)I found the problem.
The bean that I did for him findByPrimaryKey() has 1 to 1 relationship with other bean. The other bean was loaded first and because of the commit option A, it put the primary key of the realtionship bean in cache without validating it really exists it in the data base, and it wasn't in the data base.
When I did findByPrimaryKey() it looked in the cache and returned, and after when I invoked bussiness operation it throw RuntimeException beacuse it could'nt find it in the data base.
It was problem with my data, but JBoss can throw more understandable exception.