The question is: are your DTOs mutable?
If they are, this is a possible scenario:
Given 3 "records" with PKs being A,B,C.
Thread 1 Thread 2
Executes finder: result DTOs{A,B,C}
Updates DTO{A}
(new version) - Commits
Executes finder: result DTOs{A,B}
Merges finders: result DTOs{A*,B,C}
After the merge, it's difficult to predict which version of A will the
Set contain(probably, the older one). It also depends on transaction
isolation and demarcation.
When deciding for/against this kind of behavior remember to ask yourself
these questions:
How probable is the scenario?
Does this impact your app's functionality?
Adding a version field(and perhaps a dirty field too?), a version-aware
equality method in your DT and complementing that with a more specific
Set (basically, overriding add(), contains(), remove() ) could be a
solution that suits your problem.
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Hixson
> Sent: Tuesday, January 28, 2003 4:35 AM
> To: [EMAIL PROTECTED]
> Subject: DTO.equals()
>
>
> I'm considering overriding equals on one of our DTO classes
> and am considering having it only compare against the PK
> field of the foreign DTO. Has anyone else done this? Is
> there anything to watch out for in doing this?
> I have Collections returned from a number of finders and I
> convert the contents of those Collections into their
> respective DTO objects. I'd like to toss all of the DTOs into
> one of the Set objects and have it automagically unique-ify
> things for me since some of the results from the finders
> overlap and I only need one of each item in my group of DTOs.
> Thanks,
> -M@
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "signoff EJB-INTEREST".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
