 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | data update best practices | data update best practices 2004-04-21 - By James Telfer
Back
Guy,
The 4 methods I know of are:
1. All
2. Infer
3. Flag
4. Bag
(1) is the simplest, as you've mentioned, but I must question whether this
strategy will have the impact on performance that you suggest - I'd be
interested to hear if any of the readers of the list can shed some light on
this with empirical data. There are some situations (such as where change
auditing at the database level is performed) where this isn't a great idea
from other perspectives. For simplicity, though, this is so much easier -
unless performance is /that/ much of a concern.
(2) perform equality checks to infer if a change is required. This doesn't
work well and is definitely not performant.
(3) flags, as you mentioned, along the lines of what XDoclet generates. The
only difficulties with this approach are more complex query generation (for
BMP) and bean update logic. If the value object is not used by a Java client
(if, say, it is serialised via CORBA and instantiated by a different
platform) then you will have to make sure that the client application
correctly sets the flags - something of a pain in the neck, particularly
where code generation is involved.
(4) is one I have no experience with, but you /could/, in theory, send a map
containing only changed values back to the server. This may not reduce
overhead all that much, but it may have some advantages for more dynamic
views.
This may not be much help - I can only suggest that you test your solution
to see if it really does make a difference to performance (and if you do,
please post your results :) ). I'm hoping that others will shoot me down if
I'm way off beam.
HTH,
JT
-- --Original Message-- --
From: Guy Katz [mailto:gkatz@(protected)]
Sent: Wednesday, 21 April 2004 19:43
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: data update best practices
hi;
maybe i wasnt so clear on my intention.
my dilema is choosing between the foolowing options:
1. application client updates small amount of attributes on my VO -> send it
to the EJB facade -> EJB layer sets all attributes of the VO on the
corresponding domain object/s
2. 1. application client updates small amount of atributes on my VO -> send
it to the EJB facade -> EJB layer layer sets only changed attributes on
corresponding domain object/s.
option number 1 is trivial but has overhead of updating all the VO
attributes back to the domain model.
options 2 is requires a ' dirty attribute mechanism' which is extra code but
can increase performance.
any sugegstions? know practices for this?
thanks.
-- --Original Message-- --
From: Aaron Tubman [mailto:aharon@(protected)]
Sent: Wednesday, April 21, 2004 12:03 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: data update best practices
I suggest to update all the VO fields. In such way you can reuse the
same code in different situations while overhead of DB update and object
transfer is minor.
Aaron
-- --Original Message-- --
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)] On Behalf Of Guy Katz
Sent: Wednesday, April 21, 2004 11:44 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: data update best practices
hi all;
i have a situation where i pass a value object to a client. the client
will usually need to modify 1 or 2 attributes on the VO (which has many
attributes). i need to submit the changes back to the server. what i
havnt decided is if its valid to update all my data according to the
'new VO' (which is my old VO with minor changes) or just update the
fields that have chaned. in order to update the fields that have
changed, i need to add flags to indicate dirty attributes and i dont
know if i like it architecture wise.
are there any patterns for such updates?
thanks.
__ ____ ____ ____ __
Guy Katz
Allot Communications
gkatz@(protected)
tel: +972 9 7619288
fax: +972 9 7443626
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
