interesting yes that would break jboss.  We verify copies (think byte[]
comparison, which is pretty much what the MarshalledObject does for
equals)....

Rickard time to move to the incremented key with failsafe ops like we
discussed, and then stuff like that is not even covered :(((

marc


|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters
|Sent: Thursday, November 09, 2000 11:42 AM
|To: 'jBoss'
|Subject: RE: [jBoss-User] Two instances of one entity?
|
|
|Does this mean that jBoss is really performing some operation on
|my PK class
|to determine if two PKs are equal which is different than calling the
|.equals method?  I am contemplating putting a few bits of extra information
|into the PK class which isn't really part of the PK and if that will throw
|off jBoss in figuring out which entities are the same then I'll
|have to come
|up with a better way...
|
|-----Original Message-----
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 08, 2000 12:41 PM
|To: jBoss
|Subject: RE: [jBoss-User] Two instances of one entity?
|
|
|uhmmmmmm
|
|what really surprises me is that the PrimaryKey hash is today "foolproof"
|unless we are missing something.  I believe it is something else, however
|what I find strange is that the proxy that we returns the PK.  Can we see
|your PK, are you *SURE* they are exactly the same, that is the
|only reason I
|can find for a cache miss.
|
|BTW for gorabillia the PK is put in a MarshalledObject (serializable) and
|the hash and equals work on the binary representation (java library) of the
|object so EVEN if you MISS Object and equals overwriting the above trick
|works around it.  That is what it is designed to do, in other words, 2 PK
|with the same fields will MO.hash and equals to the right value no matter
|what, if they mo.hash equals to different values they are not equal. The
|ONLY reason I can see right now is that the keys you return from BMP are
|different?  if you establish that they are indeed equal they there might be
|a problem but we haven't seen up to now... make sure.
|
|I need to work on the website, Rickard are you on top of this? any other
|ideas????
|
|marc
|
|
||-----Original Message-----
||From: [EMAIL PROTECTED]
||[mailto:[EMAIL PROTECTED]]On Behalf Of Lorenz_JBoss
||Sent: Wednesday, November 08, 2000 9:29 AM
||To: 'jBoss'
||Subject: [jBoss-User] Two instances of one entity?
||
||
||Hi,
||I have written an entity bean with tho finder methods:
||findByPrimaryKey(String id) and findByCommission(String c).
||For findByCommission I have defined a SQL-statement in jaws.xml.
||
||To access the entities, the client provides some methods which uses
||different finders.
||
||But, if I change values of an entity which was found by findByCommission,
||and then use findByPrimaryKey to access that entity again, I see
|none of my
||previous changings!
||
||I found a possible workaround: if I have to use findByCommission to access
||an entity, I do it this way:
||
||      Enumeration e = findByCommission(c);
||      while(e.hasMoreElements()) {
||        Commission com = (Commission)e.nextElement();
||        com = CommissionHome.findByPrimaryKey(com.getID());
||      ...
||
||In the log then I saw, jBoss does first two ejbLoad calls and
||after doing my
||changings, two ejbStore calls.
||One of the ejbStore calls contains the original unchanged values and the
||other the changings - but both with the same primary key!
||
||Any ideas?
||
||Juergen
||
||
||
||--
||--------------------------------------------------------------
||To subscribe:        [EMAIL PROTECTED]
||To unsubscribe:      [EMAIL PROTECTED]
||Problems?:           [EMAIL PROTECTED]
||
||
|
|
|
|--
|--------------------------------------------------------------
|To subscribe:        [EMAIL PROTECTED]
|To unsubscribe:      [EMAIL PROTECTED]
|Problems?:           [EMAIL PROTECTED]
|
|
|--
|--------------------------------------------------------------
|To subscribe:        [EMAIL PROTECTED]
|To unsubscribe:      [EMAIL PROTECTED]
|Problems?:           [EMAIL PROTECTED]
|
|



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to