10 Replies Latest reply on Jun 16, 2004 3:25 AM by Alexey Loubyansky

    Is this a jboss bug (entity setter mehod)?

    vying Newbie

      Hi,all,
      I am wondering how the behavior of a setter method would be for one side of the 1-to-many relations . Base on EJB spec 2.x ,if we use the setter method to set a new relationship,then the old relations are "clear" before the new relationships are established. which means the old referential integrity are removed from the respective tables in Database .
      But I find a strange behavior with a compoud pk with jboss.Here
      is an example:
      Two entitybeans,say A and B , where their underlying tables are Table A and B in the Database.For A the primary key is Pk_1, B's primary key is compound (Pk_1,B1),where B1 is another column in table B. we have a setter method in entitybean A for the relationship of bean B,say setBs(Collection collectionOfBs),based on EJB spec, jboss container is supposed to perform "clean" job, which dissassociate those old rows in table B with Table A before setting those new relationships in table B .But jboss seems to add new relationship without disassociate the old ones.Any ideas
      Thanks

        • 1. Re: Is this a jboss bug (entity setter mehod)?
          Alexey Loubyansky Master

          The database is updated at synchronization time, i.e. at tx commit, before the finder or select method, before remove. Not just before CMR setter invocation.

          • 2. Re: Is this a jboss bug (entity setter mehod)?
            vying Newbie

            I am not quite clear of what your saying.
            Based on my observation, the outcome is after all the related transactions are commited,the old relationship are still there while new ones are added. Is this a supposed behavior?Thanks

            • 3. Re: Is this a jboss bug (entity setter mehod)?
              Alexey Loubyansky Master

              So, it is a one to many relationship from A to B (1 A has many Bs), right?
              B table should have a foreign key. Could you describe:
              - what data (specifically foreign key) was in table B before and after CMR setter invocation;
              - what did the CMR getter return before and after the setter invocation?

              • 4. Re: Is this a jboss bug (entity setter mehod)?
                vying Newbie

                Yes, it's a 1-to-many relationship.where B has a compound primary key.
                say A's Primary Key is PK_A, B's Primary Key is (PK_A,ColB),where ColB is another column in Table B.
                The scenario like this:
                say table B's structure is like:(PK_A,ColB,ColB2) and we have a row of old data here in table B:(1000,9999,'abcd');where 1000 is a Pk in Table A which is referenced by table B.
                In A's EntityEJB ,the CMR setter is setBs(collection bs),when we tried to set a new collection with new data (1000,8888,'efgh') from A's EntityEJB with that setter, then after calling the setter,the result in DB is like:(1000,9999,'abcd') +(1000,8888,'efgh').the old one is still there
                The CMR getter seems to get them all.
                Any suggestions?

                • 5. Re: Is this a jboss bug (entity setter mehod)?
                  Alexey Loubyansky Master

                  Primary key column (PK_A in B) can't be null. You have to remove the related Bs yourself before destroying relationships.
                  I agree that the exception should be thrown in attempt to set pk column to null.

                  • 6. Re: Is this a jboss bug (entity setter mehod)?
                    Alexey Loubyansky Master

                    So what you need is either map foreign key to a non-pk column in table B or remove related Bs yourself before clearing relationships.

                    • 7. Re: Is this a jboss bug (entity setter mehod)?
                      vying Newbie

                      Alex,
                      I think the container is to handle the clearance before setting new ones whatever compound Pk exists .So will it be enhanced by Jboss in the near future?Thanks

                      • 8. Re: Is this a jboss bug (entity setter mehod)?
                        Alexey Loubyansky Master

                        What do you mean by enhancement? The only fix I can think about is to throw an exception whenever you invoke the CMR setter which modifies the primary key. The only way to destroy relationships in your case is to remove B. CMR in this case read-only.

                        • 9. Re: Is this a jboss bug (entity setter mehod)?
                          David Sills Newbie

                          Was this ever resolved? Because the EJB spec (I quote from 2.1) is painfully clear on this point:

                          "The Bean Provider can thus use the set method to move objects between the collections referenced by cmr-fields of the same relationship type in different instances. The set accessor method, when applied to a cmr-field in a one-to-many relationship thus has the semantics of the java.util.Collection methods clear, followed by addAll, applied to the target collection; and clear, applied to the source collection. It is the responsibility of the container to transfer the contents of the collection
                          instances in the same transaction context." (p. 152)

                          The question is rightly asked. The user does _not_ have to clear out the old elements of the collection, the container is obligated to do that before adding the new collection elements. Whether or not the keys are composite or simple doesn't enter into it. I haven't experimented (not so easy to make up a useful example with composite keys), but does the JBoss container (I'm using 3.2.3) not do this?

                          Thanks for your answer!

                          David Sills

                          • 10. Re: Is this a jboss bug (entity setter mehod)?
                            Alexey Loubyansky Master

                            It does. But in this case relationship can't be modified because foreigm key is mapped to the primary key.