----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Oct 2006 16:58:24 -0400
From: Elinor Nolan <[EMAIL PROTECTED]>
Subject: [Wicket-user] mainland respect
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
>had time to take a peek. looks neat. curious, why do you need to clear
>databasesession? like in count the first thing you do is dbSess.clear(); ?
>or why are you using it as a singleton? why not session-per-request? or a
>threadlocal?
Thanks for the feedback.
It's not a singleton. The dbSess, is set into the DAO. I assumes the DAO was
not a singleton, so as long as there is a DAO per user's session, there will be
a dbSess per user session. The DatabaseSession (dbSess) only keeps two pieces
of state:
1) The parameters, which get substituted in for ${} variables.
2) a Record corresponding to each pojo. (the Record does change tracking for
its corresponding POJO).
So in cases when you don't need change tracking, like deleting it's OK to clear
the session, but you don't have to. You DO want to clear the session after you
flush state out to the database, like when you do an update.
>if you are going to use this to sell shades to noobs i would change a few
>things that would scare them away:
>instead of ORMDictionary dict = ShadesORMDictionary.getInstance(); i would
>make it a spring bean and get it through the context - the whole point of
>spring is to get rid of static injection.
>same for orm property of the dao
good suggestion
>same for dbsession if its really meant to be used that way - as a singleton
>need some connection support code to implement
>single-connection-per-request. it sucks that every dao op pulls a connection
>from the datasource imho - cant have transactions that span multiple calls
>to dao?
OK, I just implemented the DAO this way, because it appeared this DAO didn't
need anything more. This is part of the DAO coding.
>need to get rid of all the try/catch/finally - that code looks scarry and is
>replicated in every method
My thought there was that, sure it could get pushed to some utility class. I'm
new to Spring. I don't want to just make some utility class that pushes the
code somewhere else. If there's some way to make the try catches go away, by
somehow having Spring manage it, that makes sense.
>another thing that would be great to see is how associations are handled -
>phonebook is not really meant to demo the persistence framework, more the
>integration thereof with wicket.
>oh, and when i load it up and hit the list page i see the query to select
>all the contacts followed by a select-by-id query for each contact, why is
>that? bug?
As far as I could tell this is due to how the Phonebook code invokes the DAO. I
was going to ask you why the DAO is used in such a way that it gets the
collection, then reloads each item of the collection. I believe this is because
the phonebook is detaching and reataching the pojos. This one thing that is
great about Shades. You don't need any sort of detachment bunk, because the
DatabaseSession is serializable, along with all the POJO's. So in order to
eliminate the loads that occur each time you get an object by ID, you have to
not invoke the method of the DAO that gets the object by ID, and that,
unfortunately, is out of my hands.
>nice job,
Thanks! my pleasure.
-igor
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
