Is the Hibernate L2 cache a distributed cache?
Because, if it isn't, just bear in mind that detaching your POJO no longer
saves any memory, since the cache is holding a reference to your POJO.
With regard to the Pages, and other session variables, could you walk me
through how detachment works in Wicket? I was under the impression that stuff
was getting serialized out.
I want to point out, that Shades is extemely efficient with regards to memory.
First off, in Shades, POJO's loaded by Shades *never* have live references to
other POJO's. It's a radical design choice, but one I feel is justified, for
both performance, and streamlining. In Shades, if you want to access a
non-primitive field of a POJO, you must retrieve it explciitly by query. So
when you serialize out a POJO, that was loaded by Shades, you never have to
worry that it might have dragged an entire object-web out of the database with
it.
Secondly, shades doesn't have this confusing notion of the cache (or "pseudo
cache") that JDO has. I really don't think it is well understood by many
persitence programmers that the JDO cache is a weak cache. If you are holding
onto an ID, for the purpose of clearing the POJO's references from memory, the
POJO will NOT be in the cache when you do getObjectByID. The PersistenceManager
is going to materialize the POJO, by reading *through* the cache to the
database, so you get no performance or scalability benefits from a JDO cache in
this environement.
Finally, and now we are really getting into the realm of religion, a few words
about L2 cache. In my opinion, the database *is* the L2 cache. It's got query
caching, clustering and replication, and it's got a networked interface, which
makes it an "out of process L2 cache". In my opinion, L2 caches implemented in
the persistence layer are a crutch to support applications that do N+1 loading.
Hope this leads to some interesting discussion!
-geoff
----- Original Message ----
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, October 31, 2006 10:09:20 PM
Subject: Wicket-user Digest, Vol 5, Issue 272
Send Wicket-user mailing list submissions to
wicket-user@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wicket-user
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wicket-user digest..."
Today's Topics:
1. Re: Shades Phonebook --- why each object loaded redundantly
(Igor Vaynberg)
----------------------------------------------------------------------
Message: 1
Date: Tue, 31 Oct 2006 22:09:15 -0800
From: "Igor Vaynberg" <[EMAIL PROTECTED]>
Subject: Re: [Wicket-user] Shades Phonebook --- why each object loaded
redundantly
To: wicket-user@lists.sourceforge.net
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
ive been meaning to take a look into this and emberassingly enough it was a
bug in the ContactDetachableModel which i have now fixed, the reason i didnt
see it in hibernate is also explained below...
On 10/31/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
>
> Ragarding the Phonebook, I looked into why each Contact gets selected,
> AFTER the first select has retrieved all of them (N+1 loading).
>
> The DetachableContactModel is holding onto the ID, then getting the object
> by ID when it reattaches.
actually this wasnt the reason. the model i used never thought it was
attached (had the full version of the object) so it would load the object
twice in the same request. this has now been fixed.
If I change the detachableContactModel to just go ahead and hang onto the
> Contact, rather than the Contact's ID, then we don't see this N+1 loading.
>
> Could I suggest that rather than hanging on to an ID, we just hang onto
> the Contact itself? It's perfectly OK to serialize the Contact using Shades,
> as well as the Shades DatabaseSession.
no, it is not perfectly ok. in web apps, at least with current clustering
tech, session space is very valuable.
while it would not cause serialization errors it would _dramatically_
increase the size of session that potentially needs to be replicated across
the cluster. this is the reason why wicket has detachable models and
components. the point of the model is to load the object from the database
and make it available for the duration of the request, then at the end of
the request dump the object and only retain the minimum state necessary to
load that object when it is needed at the next request. this way only that
minimum state is replicated across the cluster.
in this particular case we are only storing the id of the object (a long)
instead of the entire Contact object.
By the way, I believe you will see this same "N+1" loading using JDO, since
> you are nulling the reference to Contact. This means, under JDO, the Contact
> is subject to garbage collection from the PM's cache. So if you are not
> seeing N+1 behavior under JDO, using this DetachableContactModel, it is only
> because you are getting lucky between passes of the garbage collector. Crank
> up the load and you will see N+1 loading when the GC kicks in, even in JDO.
the reason why i didnt see this with hibernate and the reason why n+1 and
detachable models are not a big problem with hibernate is because it has a
second level cache:id->entity.
so lets say i load a contact on the first request. it is loaded into the
cache and is returned to me. on the next request after the model is detached
and tries to load it it now performs a load-by-id, hibernate first tries
the second level cache, then the database. since it finds it in the cache
there is never a database hit. second level cache is not a subject to GC so
that is not a problem.
Perhaps I could benefit from a better explaination of what the
> DetachableContactModel accomplishes.
see above.
-igor
FYI, I ran the Phonebook with Ibatis, and the same is true. It is doing N+1
> loading, you can see from what get's printed to the screen, that for each
> Contact being shown, a select gets executed. So that also indicates that the
> N+1 loading is a function of the Phonebook DetachableContactModel, not per
> say, the persistence layer.
>
> Here is a cut and paste, running on Ibatis, showing the same N+1 loading.
>
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100263}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT
>
> ORDER BY lastname asc
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100263}
> Parameters: []
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100263}
> Types: []
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} ResultSet
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [24, Joshua, Hall, [EMAIL PROTECTED], 868-555-2136]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [23, Timothy, Hall, [EMAIL PROTECTED], 876-555-3227]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [32, Samantha, Johnson, [EMAIL PROTECTED], 885-555-8862]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [1, Pamela, Jones, [EMAIL PROTECTED], 228-555-5337]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [18, Linda, Moore, [EMAIL PROTECTED], 420-555-4812]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [33, Keith, Murray, [EMAIL PROTECTED], 502-555-6611]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [9, Virginia, Murray, [EMAIL PROTECTED], 827-555-7136]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [2, Jack, Murray, [EMAIL PROTECTED], 284-555-7438]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [31, Samantha, Nelson, [EMAIL PROTECTED], 484-555-8236]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100264} Result:
> [30, Debra, Rose, [EMAIL PROTECTED], 426-555-3144]
> 2006-10-31 21:20:54,234 DEBUG java.sql.Connection - {conn-100265}
> Connection
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100266}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100266}
> Parameters: [24]
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100266}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100267} ResultSet
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100267} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,234 DEBUG java.sql.ResultSet - {rset-100267} Result:
> [24, Joshua, Hall, [EMAIL PROTECTED], 868-555-2136]
> 2006-10-31 21:20:54,234 DEBUG java.sql.Connection - {conn-100268}
> Connection
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100269}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100269}
> Parameters: [23]
> 2006-10-31 21:20:54,234 DEBUG java.sql.PreparedStatement - {pstm-100269}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100270} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100270} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100270} Result:
> [23, Timothy, Hall, [EMAIL PROTECTED], 876-555-3227]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100271}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100272}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100272}
> Parameters: [32]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100272}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100273} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100273} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100273} Result:
> [32, Samantha, Johnson, [EMAIL PROTECTED], 885-555-8862]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100274}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100275}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100275}
> Parameters: [1]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100275}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100276} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100276} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100276} Result:
> [1, Pamela, Jones, [EMAIL PROTECTED], 228-555-5337]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100277}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100278}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100278}
> Parameters: [18]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100278}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100279} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100279} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100279} Result:
> [18, Linda, Moore, [EMAIL PROTECTED], 420-555-4812]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100280}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100281}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100281}
> Parameters: [33]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100281}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100282} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100282} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100282} Result:
> [33, Keith, Murray, [EMAIL PROTECTED], 502-555-6611]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100283}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100284}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100284}
> Parameters: [9]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100284}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100285} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100285} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100285} Result:
> [9, Virginia, Murray, [EMAIL PROTECTED], 827-555-7136]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100286}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100287}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100287}
> Parameters: [2]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100287}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100288} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100288} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100288} Result:
> [2, Jack, Murray, [EMAIL PROTECTED], 284-555-7438]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100289}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100290}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100290}
> Parameters: [31]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100290}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100291} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100291} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100291} Result:
> [31, Samantha, Nelson, [EMAIL PROTECTED], 484-555-8236]
> 2006-10-31 21:20:54,250 DEBUG java.sql.Connection - {conn-100292}
> Connection
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100293}
> PreparedStatement: SELECT id, firstname, lastname, email, phone FROM
> CONTACT WHE
> RE ID = ?
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100293}
> Parameters: [30]
> 2006-10-31 21:20:54,250 DEBUG java.sql.PreparedStatement - {pstm-100293}
> Types: [java.lang.Long]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100294} ResultSet
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100294} Header:
> [ID, FIRSTNAME, LASTNAME, EMAIL, PHONE]
> 2006-10-31 21:20:54,250 DEBUG java.sql.ResultSet - {rset-100294} Result:
> [30, Debra, Rose, [EMAIL PROTECTED], 426-555-3144]
> 2006-10-31 21:20:54,265 DEBUG java.sql.Connection - {conn-100295}
> Connection
> 2006-10-31 21:20:54,265 DEBUG java.sql.PreparedStatement - {pstm-100296}
> PreparedStatement: SELECT DISTINCT LASTNAME FROM CONTACT ORDER BY
> LASTNAME
>
>
>
> I also verified that if I change the DetachableContactModel to just hang
> onto the Contact, rather than nulling it, and NOT dao.load onAttach, that
> the N+1 loading goes away on both Shades, and Ibatis. So, if I change
> DetachableContactModel like this:
>
>
> /**
> * Uses the DAO to load the required contact when the model is
> attatched to the request.
> */
> protected void onAttach() {
> //contact=dao.load(id); //<------DON'T RELOAD
> }
>
> /**
> * Clear the reference to the contact when the model is detatched.
> */
> protected void onDetach() {
> //contact=null; //AND DON'T KILL THE REFERENCE
> }
>
> /**
> * Called after attatch to return the detatchable object.
> * @param component The component asking for the object
> * @return The detatchable object.
> */
> protected Object onGetObject(Component component) {
> return contact;
> }
>
> you can see from Shades, AND the ibatis screen output, that the N+1
> loading goes away. Here is the IBatis output after the change:
>
> 2006-10-31 21:36:47,046 DEBUG java.sql.PreparedStatement - {pstm-100161}
> Parameters: []
> 2006-10-31 21:36:47,046 DEBUG java.sql.PreparedStatement - {pstm-100161}
> Types: []
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100162} ResultSet
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100162} Header:
> []
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100162} Result:
> [35]
> 2006-10-31 21:36:47,046 DEBUG java.sql.Connection - {conn-100163}
> Connection
> 2006-10-31 21:36:47,046 DEBUG java.sql.PreparedStatement - {pstm-100164}
> PreparedStatement: SELEC
>
> ORDER BY firstname asc
> 2006-10-31 21:36:47,046 DEBUG java.sql.PreparedStatement - {pstm-100164}
> Parameters: []
> 2006-10-31 21:36:47,046 DEBUG java.sql.PreparedStatement - {pstm-100164}
> Types: []
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} ResultSet
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Header:
> [ID, FIRSTNAME, LASTNAME, E
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [21, Jose, Clark, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [29, Joshua, Wilson, joshua
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [12, Joshua, Williams, josh
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [18, Keith, Ortiz, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [14, Keith, Nelson, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [10, Maria, Brown, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [7, Maria, Smiith, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [1, Maria, Lee, [EMAIL PROTECTED]
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [25, Matthew, Donahue, matt
> 2006-10-31 21:36:47,046 DEBUG java.sql.ResultSet - {rset-100165} Result:
> [6, Pamela, Murray, pamela@
> 2006-10-31 21:36:47,062 DEBUG java.sql.Connection - {conn-100166}
> Connection
> 2006-10-31 21:36:47,062 DEBUG java.sql.PreparedStatement - {pstm-100167}
> PreparedStatement:
>
> 2006-10-31 21:36:47,062 DEBUG java.sql.PreparedStatement - {pstm-100167}
> Parameters: []
> 2006-10-31 21:36:47,062 DEBUG java.sql.PreparedStatement - {pstm-100167}
> Types: []
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} ResultSet
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Header:
> [LASTNAME]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Allen]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Bailey]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Brown]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Clark]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Cruz]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Davis]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Donahue]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Fisher]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Gomez]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Johnson]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Lee]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Moore]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Murray]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Nelson]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Ortiz]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Rose]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Smiith]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Williams]
> 2006-10-31 21:36:47,062 DEBUG java.sql.ResultSet - {rset-100168} Result:
> [Wilson]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -geoff
>
>
>
>
>
>
>
>
> ____________________________________________________________________________________
> Everyone is raving about the all-new Yahoo! Mail
> (http://advision.webevents.yahoo.com/mailbeta/)
>
>
> -------------------------------------------------------------------------
> 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
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=wicket-user/attachments/20061031/3daf359e/attachment.html
------------------------------
-------------------------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
End of Wicket-user Digest, Vol 5, Issue 272
*******************************************
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates
(http://voice.yahoo.com)
-------------------------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
