12 Replies Latest reply on Mar 19, 2002 8:19 AM by hubs2121

    JBossCMP fine with commit-option A?

    pazu

      Is JBossCMP fine with commit-option A? I'm developing an application and user JBoss-3.0.0 as app server as I believe it will be stable when I finish my app.

      Anyone, here is the situation. I changed standardjboss.xml so that JBossCMP uses commit-option A for CMP2 Entity Beans. I'm trying to boos my app performance. My app is the only one acessing the DB, so I thought it was safe to use A.

      However, strange things are happening with Collection valued CMR fields. If I add an item to the collection and later lookup the bean again, the item is there twice. There is only one insert in the database, however. It seems the item is being added to the cached collection and later added again when read from the DB. Strange, very strange.

      Everything works fine with commit-option B. I can provide full source code if needed.

        • 1. Re: JBossCMP fine with commit-option A?
          pazu

          Things are getting stranger. Just noticed that these newly-inserted items have NO PRIMAY KEY. Selecting from the database shows the generated ID's, but the items in the CMR collection have no ids.

          Also, now it seems that commit option B also got the same prablem, so it's not a commit option issue... I think I'll take a look at (xdoclet) generated source to see if I can find the source of this problem.

          • 2. Re: JBossCMP fine with commit-option A?
            dsundstrom

            Quick question while you track this down: Are you using a custom pk? If so did you correctly implement equals? If not just ignore.

            • 3. Re: JBossCMP fine with commit-option A?
              pazu

              Sorry, folks. That was a problem with xDoclet generated Value Objects (which I's somewhat responsible for). I've already submited a patch and it should be commited soon.

              If you're having the same problem, checkout xDoclet from CVS. The problem will be solved there. If you don't wanna fiddle with CVS version, contact me and I'll provide the patch.

              I feel dumb. A topic where all posts are mine.

              • 4. Re: JBossCMP fine with commit-option A?
                pajama

                What was the problem with XDoclet?

                Thanks,

                Ricardo

                • 5. Re: JBossCMP fine with commit-option A?
                  hubs2121

                  Can you explain the xdoclet problem further? I am using XDoclet and value objects as well, and I have a problem where updates made to the database from an external application are not being being picked up by my beans. Could this be related? I have made sure the commit config for JBoss is NOT set to A, so I am not sure why this is happening.

                  Thanks,

                  Steve

                  • 6. Re: JBossCMP fine with commit-option A?
                    pazu

                    The problem with xDoclet VO's is that all ValueObjects are created the first time they're requested (or at bean create time, for eager instatiation VO's) and never recreated again for that bean. The further times the VO is requested an internal cached instance is returned.

                    hubs, the bad news is that my patch won't solve your problem, I think. What my patch does is to invalidate the internally cached VO when the VO setter is called.

                    The setter does a lot of database work, so I thought it's better to invalidate the internal instance and let it be recreated (from database data) the next time it's requested than to make sure all DB changes are reflected in the VO.

                    In your case, the database is being changed in the back of the application, so there is no way for the bean to know when to reload the value object. This is really a VO deficiency. I'll write something to solve this now. Wait some time for a patch...

                    • 7. xDoclet patch
                      pazu

                      Well, here is the patch. I added the "volatile" parameter to the @ejb:value-object tag. If you specify @ejb:value-object volatile="true" then the VO will not be internally cached. I think this solves your problem.

                      I'm submitting this patch to xdoclet now. It should be in CVS version as soon as Vincent gets some time to commit this.

                      By the way: this patch is against the current (2002/03/15 14:18 GMT) CVS version.

                      • 8. Re: xDoclet patch
                        hubs2121

                        Thanks, pazu!
                        I will check it out and see if that does the trick.
                        The only problem is that I have highly customized my version of the valueobject source so that it would work properly for what I wanted.
                        I haven't looked at the most recent cvs...does it now work properly with CMP2.0? If I remember correctly, I ran into several problems with how variables were named for PKs and relations.

                        Thanks,

                        Steve

                        • 9. Re: xDoclet patch
                          pazu

                          I think it is working fine now. I've been putting a lot of work into value objects in the last few weeks. I'm using them in my own CMP2 project. Check it out :)

                          • 10. Re: xDoclet patch
                            hubs2121

                            pazu,
                            I still have the same problems with the latest version from cvs.
                            At least two problems that I have encountered are:

                            In ejbLoad() and getMyBeanValue(), improperly formatted method calls are made when trying to set the value for a cmr field. For example, here is the line that is generated -
                            PersonnelValue.setDepartmentValue( getDepartment().getcom.elequip.interfaces.DepartmentValue() );

                            As you can see, it should be just getDepartmentValue() and the fully qualified class name should be included.

                            Secondly, in the setMyBeanValue() method, the same variable names get defined more than once for "pk" and "relation" if the method has to set the values for more than one cmr field.

                            I think these are all easy to fix, and I had my own (very ugly) hack to fix them, but I'd like to see it properly done and commited if possible, in case others run into the same thing.

                            Thanks,

                            Steve

                            • 11. Re: xDoclet patch
                              pazu

                              Ah, you shouldn't use the full classname (com.elequip.interfaces.DepartmentValue) in the VO tag. Use just the short classname (DepartmentValue) and make sure it's imported.

                              The duplicate variable definition problem has been fixed in my latests patches. Wait for a few days as xDoclet is now going through a massive refactoring. There are many patches pending, mine included I think. If you're really brave you may want to check out the latest version then apply the above patch.

                              • 12. Re: xDoclet patch
                                hubs2121

                                Great, I can wait until the patches are commited, that's no problem.
                                One other thing I think I ran into was the use of getHome() instead of getLocalHome() when finding the pk for a related bean.
                                For CMP2.0, this should be getLocalHome(). Am I right, or am I doing something wrong, again! :)

                                Thanks,

                                Steve