data update best practices

Google

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

Subjects

•	JSP editor plugin for eclipse ?
•	org apache jasper JasperException: Unable to compile class for JSP
•	Tomcat: Connection reset by peer: socket write error
•	Cannot retrieve definition for form bean null
•	Struts Tiles Tutorial (free Struts training)
•	Where do I download Tomcat 4 0 6?
•	Data Access Object (DAO) pattern, example DAO 's
•	Where to download Tomcat v 4 1 24 from?
•	Tomcat 5 0 16 Requested resource not available
•	Oracle Connection Pooling in 3 2 2
•	Servlet : Session invalidate
•	Servlet action is currently unavailable
•	Tomcat/Struts Unicode Encoding/Decoding problems
•	Tomcat and webapplication specific java library path
•	Running a Simple JMS Example
•	Mapping in workers2 properties
•	org apache jasper JasperException
•	Cannot find message resources under key org apache struts action MESSAGE
•	problem with html:text bean throwing exception
•	Cannot find message resources under key org apache struts action MESSAGE
•	invalid direct reference problem with solution
•	Tool for jsp debug Try Sysdeo Eclipse Plugin
•	Tomcat 5 Cannot load JDBC driver class 'null ' SQL state: null
•	weblogic ejbc
•	java properties file
•	Jboss 3 2 3 Coyote Can 't re
•	Tomcat 5, Apache2 and mod jk2 integration problem
•	JBoss example problem new to J2EE
•	url string for connecting jboss to oracle
•	Value attribute of <html:checkbox
•	javax servlet ServletException: BeanUtils populate
•	HTTP Status 404 The requested resource is not available
•	5 0 18: Windows XP Pro vs Windows 2000

data update best practices

data update best practices

2004-04-21 - By Ovidiu Pitic

Back

Reply: 1 2 3 4 5 6 7 8

Correct. My mistake here.
I must have confused Petstore with an application I studied in my early J2EE
days (unfortunately I cannot recall which one).

Hope you have enough info without sample code.

Ovidiu

-- --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 14:06 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: data update best practices

thanks.
as far as i know. sun did not use any of the methods you suggested. in the
petstore, the VOs generation come from the entity beans and hold all the
bean's attributes.
the user/password attributes are the only attributes of the user EJB and not
a custom VO.
did i miss what you were trying to say?

-- --Original Message-- --
From: Ovidiu Pitic [mailto:OvidiuP@(protected)]
Sent: Wednesday, April 21, 2004 12:39 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: data update best practices

The accepted solution is to use custom value objects that hold only the
changed data. For example, if only the user name is changed for a user VO,
use a CVO (or CTO) that has only userId and userName as fields. For more
info, see Sun's demo apps.

The business object will be responsible of updating only the changed values
(in overloaded method that accepts a certain custom VO as parameter).

For complex functionality (which require tens of CVOs), use the dirty
mechanism, as it will add insignificant overhead.

Regards,
Ovidiu

-- --Original Message-- --
From: Guy Katz [ mailto:gkatz@(protected) <mailto:gkatz@(protected)> ]
Sent: Wednesday, April 21, 2004 13:13
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)
<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

====================================================================
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)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859 (See http://iso-8859.ora-code.com)-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2657.73">
<TITLE>RE: data update best practices</TITLE>
</HEAD>
<BODY>

Correct. My mistake here. 
 I must have confused Petstore with an application I studied in
my early J2EE days (unfortunately I cannot recall which one).

Hope you have enough info without sample code.


Ovidiu

 
 

-- --Original Message-- --
 From: An interest list for Sun Java Center J2EE Pattern
Catalog
 [<A HREF="mailto:J2EEPATTERNS-INTEREST@(protected)">mailto
:J2EEPATTERNS-INTEREST@(protected)</A>]On Behalf Of Guy Katz
 Sent: Wednesday, April 21, 2004 14:06 PM
 To: J2EEPATTERNS-INTEREST@(protected)
 Subject: Re: data update best practices

 

thanks.
 as  far as i know. sun did not use any of the methods you
suggested. in the
 petstore, the VOs generation come from the entity beans and
hold all the
 bean's attributes.
 the user/password attributes are the only attributes of the
user EJB and not
 a custom VO.
 did i miss what you were trying to say?


-- --Original Message-- --
 From: Ovidiu Pitic [<A HREF="mailto:OvidiuP@(protected)">mailto
:OvidiuP@(protected)</A>]
 Sent: Wednesday, April 21, 2004 12:39 PM
 To: J2EEPATTERNS-INTEREST@(protected)
 Subject: Re: data update best practices

 
 
 

The accepted solution is to use custom value objects that hold
only the
 changed data. For example, if only the user name is changed
for a user VO,
 use a CVO (or CTO) that has only userId and userName as fields
. For more
 info, see Sun's demo apps.


The business object will be responsible of updating only the
changed values
 (in overloaded method that accepts a certain custom VO as
parameter).


For complex functionality (which require tens of CVOs), use the
dirty
 mechanism, as it will add insignificant overhead.


Regards,
 Ovidiu


-- --Original Message-- --
 From: Guy Katz [ <A HREF="mailto:gkatz@(protected)">mailto:gkatz
@(protected)</A> <<A HREF="mailto:gkatz@(protected)">mailto:gkatz@(protected)</A>
> ]
 Sent: Wednesday, April 21, 2004 13:13
 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 [ <A HREF="mailto:aharon@(protected)"
>mailto:aharon@(protected)</A>
 <<A HREF="mailto:aharon@(protected)">mailto:aharon
@(protected)</A>> ]
 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


===============================================================
=====
 Companion Site: <A HREF="http://www.corej2eepatterns.com"
TARGET="_blank">http://www.corej2eepatterns.com</A>
 J2EE BluePrints: <A HREF="http://java.sun.com/blueprints
/corej2eepatterns" TARGET="_blank">http://java.sun.com/blueprints
/corej2eepatterns</A>
 List Archive: <A HREF="http://archives.java.sun.com/archives
/j2eepatterns-interest.html" TARGET="_blank">http://archives.java.sun.com
/archives/j2eepatterns-interest.html</A>
 Unsubscribing: email "signoff J2EEPATTERNS-INTEREST"
to listserv@(protected)


</BODY>
</HTML>
====================================================================
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)