Rick,
Thanks for the response. That is a great idea "except" that once again
it results in: Unnecessary object creation and unnecessary garbage
collection.
Imagine having say 6-12 of these types of things and logging in say a
100 users... thats an extra 600-1200 "unnecessary" objects that get
created and discarded immediately. Now imagine logging in a 1000
users... 6000-12000 "unnecessary" objects created and discarded.
And in our case it is even worse as we have several Embedded objects in
each model... so you are "unnecessarily" creating the Embedded object
wrapper as well e.g. we have a TimestampDetails class that retains
"created" and "updated" times so even if we init only the "created" then
we have 2 objects getting created there... so the 6-12 objects per model
is quite "real".
Some might try to argue that I am trying to prematurely optimize and
that is bad but "unnecessary" and moreover in this case pointless object
creation should always be avoided in any system as these types of
oversights always seem to bite back when in Production.
Any other ideas? Thoughts???
--Nikolaos
Rick Grashel wrote:
Nikolaos,
Why not simply initialize the variable in the User class when it is
declared? All it sounds like you need here is a simple default value:
@Entity
public class User extends BaseModelSharedIntegerID {
@Column( name = "created" )
private Long created = System.currentTimeMillis();
public Long getCreated() { return this.created; }
public void setCreated( Long created ) { this.created = created; }
}
When your JPA provider loads the object from the database, it will
initialize the variable when it constructs the User object, but
immediately after that, it will call setCreated() with whatever the
value is in the database.
-- Rick
On Sun, Jul 4, 2010 at 10:55 AM, Nikolaos Giannopoulos
<nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
Hi,
Say we had the following rudimentary Data Object / Model class:
@Entity
public class User extends BaseModelShardIntegerID {
private Long created;
public Long getCreated() { return created; }
public void setCreated(Long created) { this.created = created; }
}
Created corresponds to the time the instance was created and
therefore although it can be externally pumped into the class in
reality the model should be capable of initializing this on its
own. There are other examples of this such as holding an internal
score and wanting it to start at 0 for example.
Now there are a couple of scenarios were this model can be utilized:
1) From a JSP Form and therefore as an attribute of an
ActionBean. Although we could populate the form with a hidden
field for this attribute and have the setter set it on the bean I
prefer not to as once again this is a rudimentary example and in
the real case we have say 6-12 fields that require
initialization. What to do - well 1 option - code the constructor
as follows:
public User() {
this.initialize();
}
private void initialize() {
this.created = System.currentTimeMillis();
}
All is great for JSP Form --> Action Bean population
2) Say we have a piece of code that needs to "create" a User
object. Quite simply:
User user = new User();
this.userDao.save(user);
3) Say we have a piece of code that needs to "load" a User
object. Quite simply:
Integer id = <some value>
User user = this.userDao.findById(id);
Except what is "really" happening in 3)???? JPA / Hibernate is
taking the object and automatically calling its constructor which
a) invokes the initialization and populates created with the
current time and then once the object is loaded from the database
created is overwritten.
Small problem right. Well not exactly. Imagine you have embedded
objects that need to implicitly initialize and you have thousands
of these users in your system say logging in... there is A LOT of
unnecessary object creation and garbage collection right off the bat.
Potential Solution:
public User(boolean initialize) {
if (initialize) this.initialize();
}
However for JPA Load we want:
public User() { this.(*false*); }
Though for Action Bean populate we want:
public User() { this.(*true*); }
Unfortunately we can't have the same zero argument constructor
coded 2 different ways...
All would be well if I used the 1st constructor and could hook
into the ActionBean creation point and invoke User(true) or is
that a bad idea?
What have others done in this case? Thoughts / recommendations?
Much Appreciated!
--Nikolaos
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first <http://sprint.com/first> --
http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
