RE: Zero-copy persistence with Struts?

[Bryan Field-Elliot]

On Fri, 2002-10-25 at 10:33, Craig R. McClanahan wrote:


> Conceptually, one can imagine a RowSet implementation that did not copy
> anything unless you tried to *modify* existing data, at which point it
> would keep "dirty" copies of the data that was changed.  As long as the
> underlying ResultSet was scrollable, I'd bet you can avoid even the
> reference copying for the most common scenarios.
> 
> Of course, any strategy like this still has to deal with the fact that the
> underlying ResultSet and Statement really do need to be closed (and the
> connection returned to the pool if you're using one) before the current
> request completes.
> 
> 



Thanks for chiming in, Craig.

The modification use-case is frankly not interesting to me, since good
design dictates you do all your modification in the Struts Action (or
its delegate), and not in the View. What was interesting to me in the
first place, is being able to hand the View a large result set to
render, without copying each data element (or even duplicating
references) before handing it off.

As for ensuring that the JDBC primitives get closed -- not very hard,
really. My plan is to add them to a Collection after they're opened.
Save the Collection into a request-context attribute. Forward to the JSP
page. Then, lastly, a Filter picks up the Collection from the request
context, and closes all the JDBC primitives. A set of factory functions
could make these steps even easier, resulting in less code (and less
things to remember to do) in each Struts action.

Bryan

RE: Zero-copy persistence with Struts?

[Craig R. McClanahan]

On Fri, 25 Oct 2002, Frederico Schuh wrote:

> Date: Fri, 25 Oct 2002 07:01:05 -0700 (PDT)
> From: Frederico Schuh <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Zero-copy persistence with Struts?
>
> The CachedRowSet has to perform copying of data, it
> cannot keep track of references only . The ResultSet
> has a small volatile buffer that gets overwritten as
> it is iterated over. So this means that if the
> CachedRowSet stored only pointers, it would point to
> the most recent rows being fetched from the ResultSet
> at the moment.
> One of them has to perform a copy to a buffer (I
> suspect the rs.getObject() method might create a
> copy), though I am more inclined to believe the
> CachedRowSet is responsible for it.
> For memory efficient operations, ResultSet is probably
> the way to go.
>

Conceptually, one can imagine a RowSet implementation that did not copy
anything unless you tried to *modify* existing data, at which point it
would keep "dirty" copies of the data that was changed.  As long as the
underlying ResultSet was scrollable, I'd bet you can avoid even the
reference copying for the most common scenarios.

Of course, any strategy like this still has to deal with the fact that the
underlying ResultSet and Statement really do need to be closed (and the
connection returned to the pool if you're using one) before the current
request completes.

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>

Re: Zero-copy persistence with Struts?

[V. Cekvenich]

RowSet from Sun is closed source but there are way to look in.
Open Source RowSet is  at jxUtil on Sourceforge, easy to look at.

Also Oracle has RowSet as optional download to the JDBC (it is not a 
part of regular Oracle JDBC)

I found it to be fastest, easiest. My favorite part is that RowSet can 
use any SQL command with any SQL hints, etc. The slow part of a Web App 
is typically DB access for larger sites.

.V

Frederico Schuh wrote:
The CachedRowSet has to perform copying of data, it
cannot keep track of references only . The ResultSet
has a small volatile buffer that gets overwritten as
it is iterated over. So this means that if the
CachedRowSet stored only pointers, it would point to
the most recent rows being fetched from the ResultSet
at the moment.
One of them has to perform a copy to a buffer (I
suspect the rs.getObject() method might create a
copy), though I am more inclined to believe the
CachedRowSet is responsible for it.
For memory efficient operations, ResultSet is probably
the way to go.

--- Bryan Field-Elliot <[EMAIL PROTECTED]>
wrote:


On Fri, 2002-10-25 at 00:55, Hookom, Jacob John
wrote:



I guess I'm lost as to why CachedRowSet is a zero


copy?  

The source code for the basicPortal's still copies


all the data into another, internal collection.  


Regards,
Jacob






Here's how my thinking has evolved since I opened
this thread a couple
of days ago. 

If you're working in C/C++, zero-copy has a very
black-and-white quality
to it. However in Java, there's something of a
middle position, and that
is reference copying. Creating multiple references
to an object already
created, while certainly more expensive than not, is
still not really
copying the data. No object's are "new"'d, and
little impact is made
upon the garbage collector. That is to say (if I
understand the JVM
correctly), references going in and out of scope DO
impact the garbage
collector (in that they may trigger other objects to
be gc'd), but they
are not themselves gc'd. A lessened impact, but
greater than zero.

I see three possible scenarios.

1. If we assume that the "raw" data is in the
ResultSet primitive, then
the shortest, most optimal route, is to get the
ResultSet all the way to
the View (JSP pages). It can be wrapped inside
another class (a
decorator) to make it more bean-like or otherwise
more JSP friendly.
This minimizes memory use and even reference use. 

2. The next best thing is a wrapper object which
iterates through the
ResultSet, and copies all the rows and columns, by
REFERENCE, to a
different kind of collection. I suspect that this is
what CachedRowSet
does. Note that it isn't really copying the data
(e.g. no ".clone()"'s
are going on, although someone correct me if I'mw
rong), but instead
it's copying the references returned by each
ResultSet.getObject() call.

3. The worst thing would be a mechanism which
literally copies the data,
and not just the references to the data, using
clone() or something. I
can't imagine any of the persistence frameworks
actually do this.

So the question becomes - does, or does not,
reference copying qualify
as "zero-copy" as originally defined? I guess that's
a larger issue,
don't really want to tie up this Struts list with a
debate like that. 

Actually - the more I look at it - scenarios #1 and
#2 are probably
equivalent in terms of use of references. Without
going into too much
detail - a decorator class which delegates the
"gets" and "sets" to an
private object (ResultSet in scenario #1) is
probably doing just as much
reference cloning as a wrapper which iterates
through all rows at
startup and copies the references into a private
collection (scenario
#2).

It may be that CachedRowSet is as good as it gets.

Bryan




=

Frederico Ferro Schuh
[EMAIL PROTECTED]
ICQ: 20486081

__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Zero-copy persistence with Struts?

[V. Cekvenich]

Hookom, Jacob John wrote:


I guess I'm lost as to why CachedRowSet is a zero copy?  The source 
code for the basicPortal's still copies all the data into another, 
internal collection. 

No it does not.  CVS will be up, else I would link you.
Pseudo code is soemthing like this:

getNameX () {

getDAO().getRowSet().getString("namex");

}

and same on setter. See it just uses a pointer to rowset.

I code it as
getNameX () {
getProperty("namex");
}
but it is same as above.


// Isn't that copying the data or did I miss the

definition of zero copy?


That would be, but data goes to rowset and stays there (hence the name 
of diesconected row set). For high loads, I have clients with 40,000 and 
10,000 concurent Struts users, you can't copy or do new this or new 
that. That would double the number of servers my client needs.

hth, .V

//  With OJB, objects are placed in a cache, so
if you are querying the db, and a row is returned as an object, it's 
first fetched from the cache-- zero copy.  With each request with a 
CachedRowSet, aren't you instantating just as many objects each time, 
granted you aren't wrapping the columns in an object, but you are 
still wrapping them in something like an Object[] or a Map (gasp).  
Even if you were to re-use the CachedRowSet as part of an action at 
the application scope, you would be needing to load all the data for 
every user to be able to filter over as you push it to the jsp.  

To cache rowsets, you can turn on Poolmans caching, so no SQL Select 
firest, if the rowset is there already.

Please catch me if I'm mistaken.

Regards,
Jacob








--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Zero-copy persistence with Struts?

[Eddie Bush]

No, you're right Jacob.  It would, in fact, have to do a copy.  I don't, 
quite frankly, know why I misrepresented it.  I think it's still more 
minimalistic than OJB though - so the original person asking may yet 
prefer it.  I certainly would rather see a person use CRS than keeping 
ResultSets open (and Connections and ... ) ... what a headache that'd 
be.  Can you imagine all the hoops he'd have to jump through to *try* 
(because I don't think he'd always succeed) and make sure his 
connections etc always got closed?  Insane!

Hookom, Jacob John wrote:

I guess I'm lost as to why CachedRowSet is a zero copy?  The source code for the basicPortal's still copies all the data into another, internal collection.  Isn't that copying the data or did I miss the definition of zero copy?  With OJB, objects are placed in a cache, so if you are querying the db, and a row is returned as an object, it's first fetched from the cache-- zero copy.  With each request with a CachedRowSet, aren't you instantating just as many objects each time, granted you aren't wrapping the columns in an object, but you are still wrapping them in something like an Object[] or a Map (gasp).  Even if you were to re-use the CachedRowSet as part of an action at the application scope, you would be needing to load all the data for every user to be able to filter over as you push it to the jsp.  Please catch me if I'm mistaken.

Regards,
Jacob



--
Eddie Bush




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Zero-copy persistence with Struts?

[Frederico Schuh]

The CachedRowSet has to perform copying of data, it
cannot keep track of references only . The ResultSet
has a small volatile buffer that gets overwritten as
it is iterated over. So this means that if the
CachedRowSet stored only pointers, it would point to
the most recent rows being fetched from the ResultSet
at the moment.
One of them has to perform a copy to a buffer (I
suspect the rs.getObject() method might create a
copy), though I am more inclined to believe the
CachedRowSet is responsible for it.
For memory efficient operations, ResultSet is probably
the way to go.

--- Bryan Field-Elliot <[EMAIL PROTECTED]>
wrote:
> On Fri, 2002-10-25 at 00:55, Hookom, Jacob John
> wrote:
> 
> > I guess I'm lost as to why CachedRowSet is a zero
> copy?  
> > The source code for the basicPortal's still copies
> all the data into another, internal collection.  
> >  
> > Regards,
> > Jacob
> > 
> > 
> 
> 
> 
> Here's how my thinking has evolved since I opened
> this thread a couple
> of days ago. 
> 
> If you're working in C/C++, zero-copy has a very
> black-and-white quality
> to it. However in Java, there's something of a
> middle position, and that
> is reference copying. Creating multiple references
> to an object already
> created, while certainly more expensive than not, is
> still not really
> copying the data. No object's are "new"'d, and
> little impact is made
> upon the garbage collector. That is to say (if I
> understand the JVM
> correctly), references going in and out of scope DO
> impact the garbage
> collector (in that they may trigger other objects to
> be gc'd), but they
> are not themselves gc'd. A lessened impact, but
> greater than zero.
> 
> I see three possible scenarios.
> 
> 1. If we assume that the "raw" data is in the
> ResultSet primitive, then
> the shortest, most optimal route, is to get the
> ResultSet all the way to
> the View (JSP pages). It can be wrapped inside
> another class (a
> decorator) to make it more bean-like or otherwise
> more JSP friendly.
> This minimizes memory use and even reference use. 
> 
> 2. The next best thing is a wrapper object which
> iterates through the
> ResultSet, and copies all the rows and columns, by
> REFERENCE, to a
> different kind of collection. I suspect that this is
> what CachedRowSet
> does. Note that it isn't really copying the data
> (e.g. no ".clone()"'s
> are going on, although someone correct me if I'mw
> rong), but instead
> it's copying the references returned by each
> ResultSet.getObject() call.
> 
> 3. The worst thing would be a mechanism which
> literally copies the data,
> and not just the references to the data, using
> clone() or something. I
> can't imagine any of the persistence frameworks
> actually do this.
> 
> So the question becomes - does, or does not,
> reference copying qualify
> as "zero-copy" as originally defined? I guess that's
> a larger issue,
> don't really want to tie up this Struts list with a
> debate like that. 
> 
> Actually - the more I look at it - scenarios #1 and
> #2 are probably
> equivalent in terms of use of references. Without
> going into too much
> detail - a decorator class which delegates the
> "gets" and "sets" to an
> private object (ResultSet in scenario #1) is
> probably doing just as much
> reference cloning as a wrapper which iterates
> through all rows at
> startup and copies the references into a private
> collection (scenario
> #2).
> 
> It may be that CachedRowSet is as good as it gets.
> 
> Bryan
> 


=

Frederico Ferro Schuh
[EMAIL PROTECTED]
ICQ: 20486081

__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Zero-copy persistence with Struts?

[V. Cekvenich]

errr the source is in ZIP. It was in CVS, then a new programer on bP 
project droped the CVS by accident. It will take at least a day to clean 
up left over files, waiting on SF to do that. Check PM/tmrw for CVS or 
use a ZIp a bit out of date. (I have had 4 private e-mails on this)
.V

Jacob Hookom wrote:
That's the thing though, granted objects are passed by reference, but,
with cached rowset, each call to the db will result in the creation of a
new set of container objects to hold all of the fields (container for
all rows, a container for each column of that row).  The only real
resolve to this issue is to create a variation of the Flyweight pattern
where we ID the data from the resultset to prevent new'ing container
objects, much like OJB's ObjectCache class.  I think there was a
framework started in basicPortal to handler this, but I'm not sure.  I
tried to grab the source for it all, but it was still missing java
files.

-jacob

| -Original Message-
| From: Bryan Field-Elliot [mailto:bryan_lists@;netmeme.org]
| Sent: Friday, October 25, 2002 8:39 AM
| To: Struts Users Mailing List
| Subject: RE: Zero-copy persistence with Struts?
| 
| On Fri, 2002-10-25 at 00:55, Hookom, Jacob John wrote:
| 
| > I guess I'm lost as to why CachedRowSet is a zero copy?
| > The source code for the basicPortal's still copies all the data into
| another, internal collection.
| >
| > Regards,
| > Jacob
| >
| >
| 
| 
| 
| Here's how my thinking has evolved since I opened this thread a couple
| of days ago.
| 
| If you're working in C/C++, zero-copy has a very black-and-white
quality
| to it. However in Java, there's something of a middle position, and
that
| is reference copying. Creating multiple references to an object
already
| created, while certainly more expensive than not, is still not really
| copying the data. No object's are "new"'d, and little impact is made
| upon the garbage collector. That is to say (if I understand the JVM
| correctly), references going in and out of scope DO impact the garbage
| collector (in that they may trigger other objects to be gc'd), but
they
| are not themselves gc'd. A lessened impact, but greater than zero.
| 
| I see three possible scenarios.
| 
| 1. If we assume that the "raw" data is in the ResultSet primitive,
then
| the shortest, most optimal route, is to get the ResultSet all the way
to
| the View (JSP pages). It can be wrapped inside another class (a
| decorator) to make it more bean-like or otherwise more JSP friendly.
| This minimizes memory use and even reference use.
| 
| 2. The next best thing is a wrapper object which iterates through the
| ResultSet, and copies all the rows and columns, by REFERENCE, to a
| different kind of collection. I suspect that this is what CachedRowSet
| does. Note that it isn't really copying the data (e.g. no ".clone()"'s
| are going on, although someone correct me if I'mw rong), but instead
| it's copying the references returned by each ResultSet.getObject()
call.
| 
| 3. The worst thing would be a mechanism which literally copies the
data,
| and not just the references to the data, using clone() or something. I
| can't imagine any of the persistence frameworks actually do this.
| 
| So the question becomes - does, or does not, reference copying qualify
| as "zero-copy" as originally defined? I guess that's a larger issue,
| don't really want to tie up this Struts list with a debate like that.
| 
| Actually - the more I look at it - scenarios #1 and #2 are probably
| equivalent in terms of use of references. Without going into too much
| detail - a decorator class which delegates the "gets" and "sets" to an
| private object (ResultSet in scenario #1) is probably doing just as
much
| reference cloning as a wrapper which iterates through all rows at
| startup and copies the references into a private collection (scenario
| #2).
| 
| It may be that CachedRowSet is as good as it gets.
| 
| Bryan




--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>

RE: Zero-copy persistence with Struts?

[Jacob Hookom]

That's the thing though, granted objects are passed by reference, but,
with cached rowset, each call to the db will result in the creation of a
new set of container objects to hold all of the fields (container for
all rows, a container for each column of that row).  The only real
resolve to this issue is to create a variation of the Flyweight pattern
where we ID the data from the resultset to prevent new'ing container
objects, much like OJB's ObjectCache class.  I think there was a
framework started in basicPortal to handler this, but I'm not sure.  I
tried to grab the source for it all, but it was still missing java
files.

-jacob

| -Original Message-
| From: Bryan Field-Elliot [mailto:bryan_lists@;netmeme.org]
| Sent: Friday, October 25, 2002 8:39 AM
| To: Struts Users Mailing List
| Subject: RE: Zero-copy persistence with Struts?
| 
| On Fri, 2002-10-25 at 00:55, Hookom, Jacob John wrote:
| 
| > I guess I'm lost as to why CachedRowSet is a zero copy?
| > The source code for the basicPortal's still copies all the data into
| another, internal collection.
| >
| > Regards,
| > Jacob
| >
| >
| 
| 
| 
| Here's how my thinking has evolved since I opened this thread a couple
| of days ago.
| 
| If you're working in C/C++, zero-copy has a very black-and-white
quality
| to it. However in Java, there's something of a middle position, and
that
| is reference copying. Creating multiple references to an object
already
| created, while certainly more expensive than not, is still not really
| copying the data. No object's are "new"'d, and little impact is made
| upon the garbage collector. That is to say (if I understand the JVM
| correctly), references going in and out of scope DO impact the garbage
| collector (in that they may trigger other objects to be gc'd), but
they
| are not themselves gc'd. A lessened impact, but greater than zero.
| 
| I see three possible scenarios.
| 
| 1. If we assume that the "raw" data is in the ResultSet primitive,
then
| the shortest, most optimal route, is to get the ResultSet all the way
to
| the View (JSP pages). It can be wrapped inside another class (a
| decorator) to make it more bean-like or otherwise more JSP friendly.
| This minimizes memory use and even reference use.
| 
| 2. The next best thing is a wrapper object which iterates through the
| ResultSet, and copies all the rows and columns, by REFERENCE, to a
| different kind of collection. I suspect that this is what CachedRowSet
| does. Note that it isn't really copying the data (e.g. no ".clone()"'s
| are going on, although someone correct me if I'mw rong), but instead
| it's copying the references returned by each ResultSet.getObject()
call.
| 
| 3. The worst thing would be a mechanism which literally copies the
data,
| and not just the references to the data, using clone() or something. I
| can't imagine any of the persistence frameworks actually do this.
| 
| So the question becomes - does, or does not, reference copying qualify
| as "zero-copy" as originally defined? I guess that's a larger issue,
| don't really want to tie up this Struts list with a debate like that.
| 
| Actually - the more I look at it - scenarios #1 and #2 are probably
| equivalent in terms of use of references. Without going into too much
| detail - a decorator class which delegates the "gets" and "sets" to an
| private object (ResultSet in scenario #1) is probably doing just as
much
| reference cloning as a wrapper which iterates through all rows at
| startup and copies the references into a private collection (scenario
| #2).
| 
| It may be that CachedRowSet is as good as it gets.
| 
| Bryan


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>

RE: Zero-copy persistence with Struts?

[Bryan Field-Elliot]

On Fri, 2002-10-25 at 00:55, Hookom, Jacob John wrote:

> I guess I'm lost as to why CachedRowSet is a zero copy?  
> The source code for the basicPortal's still copies all the data into another, 
>internal collection.  
>  
> Regards,
> Jacob
> 
> 



Here's how my thinking has evolved since I opened this thread a couple
of days ago. 

If you're working in C/C++, zero-copy has a very black-and-white quality
to it. However in Java, there's something of a middle position, and that
is reference copying. Creating multiple references to an object already
created, while certainly more expensive than not, is still not really
copying the data. No object's are "new"'d, and little impact is made
upon the garbage collector. That is to say (if I understand the JVM
correctly), references going in and out of scope DO impact the garbage
collector (in that they may trigger other objects to be gc'd), but they
are not themselves gc'd. A lessened impact, but greater than zero.

I see three possible scenarios.

1. If we assume that the "raw" data is in the ResultSet primitive, then
the shortest, most optimal route, is to get the ResultSet all the way to
the View (JSP pages). It can be wrapped inside another class (a
decorator) to make it more bean-like or otherwise more JSP friendly.
This minimizes memory use and even reference use. 

2. The next best thing is a wrapper object which iterates through the
ResultSet, and copies all the rows and columns, by REFERENCE, to a
different kind of collection. I suspect that this is what CachedRowSet
does. Note that it isn't really copying the data (e.g. no ".clone()"'s
are going on, although someone correct me if I'mw rong), but instead
it's copying the references returned by each ResultSet.getObject() call.

3. The worst thing would be a mechanism which literally copies the data,
and not just the references to the data, using clone() or something. I
can't imagine any of the persistence frameworks actually do this.

So the question becomes - does, or does not, reference copying qualify
as "zero-copy" as originally defined? I guess that's a larger issue,
don't really want to tie up this Struts list with a debate like that. 

Actually - the more I look at it - scenarios #1 and #2 are probably
equivalent in terms of use of references. Without going into too much
detail - a decorator class which delegates the "gets" and "sets" to an
private object (ResultSet in scenario #1) is probably doing just as much
reference cloning as a wrapper which iterates through all rows at
startup and copies the references into a private collection (scenario
#2).

It may be that CachedRowSet is as good as it gets.

Bryan

RE: Zero-copy persistence with Struts?

[Hookom, Jacob John]

I guess I'm lost as to why CachedRowSet is a zero copy?  The source code for the 
basicPortal's still copies all the data into another, internal collection.  Isn't that 
copying the data or did I miss the definition of zero copy?  With OJB, objects are 
placed in a cache, so if you are querying the db, and a row is returned as an object, 
it's first fetched from the cache-- zero copy.  With each request with a CachedRowSet, 
aren't you instantating just as many objects each time, granted you aren't wrapping 
the columns in an object, but you are still wrapping them in something like an 
Object[] or a Map (gasp).  Even if you were to re-use the CachedRowSet as part of an 
action at the application scope, you would be needing to load all the data for every 
user to be able to filter over as you push it to the jsp.  Please catch me if I'm 
mistaken.
 
Regards,
Jacob

-Original Message- 
From: Frederico Schuh [mailto:fred_schuh@;yahoo.com.br] 
Sent: Fri 10/25/2002 1:41 AM 
To: Struts Users Mailing List 
    Cc: 
    Subject: RE: Zero-copy persistence with Struts?



Though I agree with the CachedRowSet solution, I don't
think using a ResultSet is bad at all. If you can find
a way to wrap it around an interface like you are
proposing, it can be cleaner to the JSP page and will
be more memory efficient than using a CachedRowSet,
and thus it will be more scalable. It will probably be
slower to iterate through, due to the fact that it
maintains an open connection and makes several calls
to fetch data through the network, but memory is
usually a more critical resource in a server.
If you plan to work with huge lists of entries, I
think you should consider using a ResultSet. The
disconnected CachedRowSet sounds nice, but if you have
a high traffic of users, I believe your server might
be very likely to fail serving the requests due to the
high memory usage.
I've never done this actually, but I think it would
perform well. Any opinions on this?


On Wed, 2002-10-23 at 12:09, Eddie Bush wrote:

> If you're set on zero-copy, CachedRowSet is probably
the best way to go.
> There is an OS implementation on sourceforge, I
believe. Vic uses it
> in basicPortal - that is his approach as well.
>
> Personally, I use OJB. If you're trying to cut out
all the "overhead"
> you can CachedRowSet would probably be the way to go
though
> (minimalistic). One of the neat things about the CRS
approach is that
> you can actually ask the RowSet to update itself,
and provide it a
> connection it will use to do so - so you can have
transactional control
> over it. At the same time, being cached
(disconnected), it does not
> require you to keep anything "open"
(connection/statement/ thing here>), so you can follow better, more
straight-forward practices
> by using it.
>
> --
> Eddie Bush

--- "Miller, Jason" <[EMAIL PROTECTED]> wrote:
> I do something similar to what you are proposing, so
> far as the
> ResultSet-to-the-view bit goes.  I have a wrapper
> class that adapts an
> Iterator interface to anything you need.
>
> So far as closing the resources go, I ended up
> coding in a requirement that
> the ResultSet only contain the data that is to be
> displayed.  This isn't as
> much of a problem as one would think, since
> normally, its a waste of time to
> get 1000 rows from a database when only 50 are being
> displayed anyway.  It
> would also be trivial to extend the class to
> configure it to display X
> number of rows and then close.
>
> The wrapper is not specific to ResultSets - it can
> wrap any source of data
> so long as a subclass is defined to transform the
> data.
>
> I can send you what I have, if you are interested,
> or post it somehow.  At
> least it may give you a starting point, and it will
> certainly explain what I
> mean better than I have done here.
>
> Jason
>
> > -Original Message-
> > From: Bryan Field-Elliot
> [mailto:bryan_lists@;netmeme.org]
> > Sent: Tuesday, October 22, 2002 10:36 PM
> > To: Struts U

RE: Zero-copy persistence with Struts?

[Frederico Schuh]

Though I agree with the CachedRowSet solution, I don't
think using a ResultSet is bad at all. If you can find
a way to wrap it around an interface like you are
proposing, it can be cleaner to the JSP page and will
be more memory efficient than using a CachedRowSet,
and thus it will be more scalable. It will probably be
slower to iterate through, due to the fact that it
maintains an open connection and makes several calls
to fetch data through the network, but memory is
usually a more critical resource in a server.
If you plan to work with huge lists of entries, I
think you should consider using a ResultSet. The
disconnected CachedRowSet sounds nice, but if you have
a high traffic of users, I believe your server might
be very likely to fail serving the requests due to the
high memory usage.
I've never done this actually, but I think it would
perform well. Any opinions on this?


On Wed, 2002-10-23 at 12:09, Eddie Bush wrote:

> If you're set on zero-copy, CachedRowSet is probably
the best way to go. 
> There is an OS implementation on sourceforge, I
believe. Vic uses it 
> in basicPortal - that is his approach as well.
> 
> Personally, I use OJB. If you're trying to cut out
all the "overhead" 
> you can CachedRowSet would probably be the way to go
though 
> (minimalistic). One of the neat things about the CRS
approach is that 
> you can actually ask the RowSet to update itself,
and provide it a 
> connection it will use to do so - so you can have
transactional control 
> over it. At the same time, being cached
(disconnected), it does not 
> require you to keep anything "open"
(connection/statement/ thing here>), so you can follow better, more
straight-forward practices 
> by using it.
> 
> -- 
> Eddie Bush

--- "Miller, Jason" <[EMAIL PROTECTED]> wrote:
> I do something similar to what you are proposing, so
> far as the
> ResultSet-to-the-view bit goes.  I have a wrapper
> class that adapts an
> Iterator interface to anything you need.
> 
> So far as closing the resources go, I ended up
> coding in a requirement that
> the ResultSet only contain the data that is to be
> displayed.  This isn't as
> much of a problem as one would think, since
> normally, its a waste of time to
> get 1000 rows from a database when only 50 are being
> displayed anyway.  It
> would also be trivial to extend the class to
> configure it to display X
> number of rows and then close.
> 
> The wrapper is not specific to ResultSets - it can
> wrap any source of data
> so long as a subclass is defined to transform the
> data.
> 
> I can send you what I have, if you are interested,
> or post it somehow.  At
> least it may give you a starting point, and it will
> certainly explain what I
> mean better than I have done here.
> 
> Jason
> 
> > -Original Message-
> > From: Bryan Field-Elliot
> [mailto:bryan_lists@;netmeme.org]
> > Sent: Tuesday, October 22, 2002 10:36 PM
> > To: Struts Users Mailing List
> > Subject: Zero-copy persistence with Struts?
> > 
> > 
> > I'm banging my brain against the sides of my skull
> trying to 
> > think of a
> > way to do zero-copy JDBC persistence with Struts.
> > 
> > What I mean by zero-copy is, basically, pass as
> much "raw data" as
> > possible between the Model layer and the View
> layer. In 
> > pragmatic terms,
> > this probably means taking a JDBC ResultSet in the
> Model layer,
> > decorating it somehow (e.g. wrapping it in a
> DynaBean, or otherwise),
> > and setting it into the Request attribute context,
> where the JSP page
> > can iterate through and display it.
> > 
> > Why bother? Performance.
> > 
> > So here's the catch... if I insert the ResultSet
> into the request
> > context, then somewhere later I need to close the
> ResultSet, and
> > probably also the Statement which produced it and
> possibly even the
> > Connection which was queried in the first place.
> It wouldn't 
> > make sense
> > from a design standpoint to put this plumbing in
> each JSP page.
> > 
> > My thinking is to build a Filter (Servlet 2.3)
> which, after all Model
> > and View classes are called (e.g. Struts actions
> and JSP pages), close
> > all the ResultSets, Statements, etc. This seems a
> little complex but
> > it's the best pattern I can come up with. I was
> hoping for 
> > some (expert)
> > opinions on this approach.
> > 
> > The basic flow would be:
> > 
> > 1. Struts Action does the following:
> >1a. grabs a connection from the pool
> >1b. create a Statement (or PreparedStatement),
> do the JDBC work,
> > obtain a ResultSet
> >1c. Decorate the ResultSet as needed (e.g. wrap
> it inside a
> > ResultSetDynaClass)
> >1d. Push the original Connection, Statement,
> and ResultSet onto a
> > request context "stack" of some kind (with an
> agreed-upon key name).
> > 2. JSP page does the following:
> >2a. Iterate through the ResultSet (or it's
> wrapper) as if it were a
> > standard collection of standard beans.
> > 3. Filter does the following cleanup:
> >3a. Retrieve the "stack

Re: Zero-copy persistence with Struts?

[Bryan Field-Elliot]

Thanks, I'll take a look.

I've never even used RowSet before... My trusty O'Reilly JDBC book
devotes a whopping 2 pages to RowSet which I conveniently overlooked.
I'll take a look at RowSet and then the CachedRowSet extension...

Bryan


On Wed, 2002-10-23 at 12:09, Eddie Bush wrote:

> If you're set on zero-copy, CachedRowSet is probably the best way to go. 
>  There is an OS implementation on sourceforge, I believe.  Vic uses it 
> in basicPortal - that is his approach as well.
> 
> Personally, I use OJB.  If you're trying to cut out all the "overhead" 
> you can CachedRowSet would probably be the way to go though 
> (minimalistic).  One of the neat things about the CRS approach is that 
> you can actually ask the RowSet to update itself, and provide it a 
> connection it will use to do so - so you can have transactional control 
> over it.  At the same time, being cached (disconnected), it does not 
> require you to keep anything "open" (connection/statement/ thing here>), so you can follow better, more straight-forward practices 
> by using it.
> 
> -- 
> Eddie Bush
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
Bryan Field-Elliot <[EMAIL PROTECTED]>

Re: Zero-copy persistence with Struts?

[Eddie Bush]

If you're set on zero-copy, CachedRowSet is probably the best way to go. 
There is an OS implementation on sourceforge, I believe.  Vic uses it 
in basicPortal - that is his approach as well.

Personally, I use OJB.  If you're trying to cut out all the "overhead" 
you can CachedRowSet would probably be the way to go though 
(minimalistic).  One of the neat things about the CRS approach is that 
you can actually ask the RowSet to update itself, and provide it a 
connection it will use to do so - so you can have transactional control 
over it.  At the same time, being cached (disconnected), it does not 
require you to keep anything "open" (connection/statement/), so you can follow better, more straight-forward practices 
by using it.

--
Eddie Bush



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Zero-copy persistence with Struts?

[Jacob Hookom]

Why not look at an OJB/Castor implementation?  Through Object caching
and identity referencing, there are (in near all cases) only a single
instance of any object in memory, plus the addition of hands-free lazy
loading of collections/relations, OJB is REALLY appealing for web
applications.

-Jacob

| -Original Message-
| From: Miller, Jason [mailto:jmiller@;ostglobal.com]
| Sent: Wednesday, October 23, 2002 11:13 AM
| To: 'Struts Users Mailing List'
| Subject: RE: Zero-copy persistence with Struts?
| 
| I do something similar to what you are proposing, so far as the
| ResultSet-to-the-view bit goes.  I have a wrapper class that adapts an
| Iterator interface to anything you need.
| 
| So far as closing the resources go, I ended up coding in a requirement
| that
| the ResultSet only contain the data that is to be displayed.  This
isn't
| as
| much of a problem as one would think, since normally, its a waste of
time
| to
| get 1000 rows from a database when only 50 are being displayed anyway.
It
| would also be trivial to extend the class to configure it to display X
| number of rows and then close.
| 
| The wrapper is not specific to ResultSets - it can wrap any source of
data
| so long as a subclass is defined to transform the data.
| 
| I can send you what I have, if you are interested, or post it somehow.
At
| least it may give you a starting point, and it will certainly explain
what
| I
| mean better than I have done here.
| 
| Jason
| 
| > -Original Message-
| > From: Bryan Field-Elliot [mailto:bryan_lists@;netmeme.org]
| > Sent: Tuesday, October 22, 2002 10:36 PM
| > To: Struts Users Mailing List
| > Subject: Zero-copy persistence with Struts?
| >
| >
| > I'm banging my brain against the sides of my skull trying to
| > think of a
| > way to do zero-copy JDBC persistence with Struts.
| >
| > What I mean by zero-copy is, basically, pass as much "raw data" as
| > possible between the Model layer and the View layer. In
| > pragmatic terms,
| > this probably means taking a JDBC ResultSet in the Model layer,
| > decorating it somehow (e.g. wrapping it in a DynaBean, or
otherwise),
| > and setting it into the Request attribute context, where the JSP
page
| > can iterate through and display it.
| >
| > Why bother? Performance.
| >
| > So here's the catch... if I insert the ResultSet into the request
| > context, then somewhere later I need to close the ResultSet, and
| > probably also the Statement which produced it and possibly even the
| > Connection which was queried in the first place. It wouldn't
| > make sense
| > from a design standpoint to put this plumbing in each JSP page.
| >
| > My thinking is to build a Filter (Servlet 2.3) which, after all
Model
| > and View classes are called (e.g. Struts actions and JSP pages),
close
| > all the ResultSets, Statements, etc. This seems a little complex but
| > it's the best pattern I can come up with. I was hoping for
| > some (expert)
| > opinions on this approach.
| >
| > The basic flow would be:
| >
| > 1. Struts Action does the following:
| >1a. grabs a connection from the pool
| >1b. create a Statement (or PreparedStatement), do the JDBC work,
| > obtain a ResultSet
| >1c. Decorate the ResultSet as needed (e.g. wrap it inside a
| > ResultSetDynaClass)
| >1d. Push the original Connection, Statement, and ResultSet onto a
| > request context "stack" of some kind (with an agreed-upon key name).
| > 2. JSP page does the following:
| >2a. Iterate through the ResultSet (or it's wrapper) as if it were
a
| > standard collection of standard beans.
| > 3. Filter does the following cleanup:
| >3a. Retrieve the "stack" of open JDBC primitives from the request
| > context.
| >3b. Close them all.
| >
| > This seems to achieve a nice level of zero-copyness without
bothering
| > the JSP page with messy plumbing details. Comments?
| >
| > Thanks,
| > Bryan
| >


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>

RE: Zero-copy persistence with Struts?

[Miller, Jason]

I do something similar to what you are proposing, so far as the
ResultSet-to-the-view bit goes.  I have a wrapper class that adapts an
Iterator interface to anything you need.

So far as closing the resources go, I ended up coding in a requirement that
the ResultSet only contain the data that is to be displayed.  This isn't as
much of a problem as one would think, since normally, its a waste of time to
get 1000 rows from a database when only 50 are being displayed anyway.  It
would also be trivial to extend the class to configure it to display X
number of rows and then close.

The wrapper is not specific to ResultSets - it can wrap any source of data
so long as a subclass is defined to transform the data.

I can send you what I have, if you are interested, or post it somehow.  At
least it may give you a starting point, and it will certainly explain what I
mean better than I have done here.

Jason

> -Original Message-
> From: Bryan Field-Elliot [mailto:bryan_lists@;netmeme.org]
> Sent: Tuesday, October 22, 2002 10:36 PM
> To: Struts Users Mailing List
> Subject: Zero-copy persistence with Struts?
> 
> 
> I'm banging my brain against the sides of my skull trying to 
> think of a
> way to do zero-copy JDBC persistence with Struts.
> 
> What I mean by zero-copy is, basically, pass as much "raw data" as
> possible between the Model layer and the View layer. In 
> pragmatic terms,
> this probably means taking a JDBC ResultSet in the Model layer,
> decorating it somehow (e.g. wrapping it in a DynaBean, or otherwise),
> and setting it into the Request attribute context, where the JSP page
> can iterate through and display it.
> 
> Why bother? Performance.
> 
> So here's the catch... if I insert the ResultSet into the request
> context, then somewhere later I need to close the ResultSet, and
> probably also the Statement which produced it and possibly even the
> Connection which was queried in the first place. It wouldn't 
> make sense
> from a design standpoint to put this plumbing in each JSP page.
> 
> My thinking is to build a Filter (Servlet 2.3) which, after all Model
> and View classes are called (e.g. Struts actions and JSP pages), close
> all the ResultSets, Statements, etc. This seems a little complex but
> it's the best pattern I can come up with. I was hoping for 
> some (expert)
> opinions on this approach.
> 
> The basic flow would be:
> 
> 1. Struts Action does the following:
>1a. grabs a connection from the pool
>1b. create a Statement (or PreparedStatement), do the JDBC work,
> obtain a ResultSet
>1c. Decorate the ResultSet as needed (e.g. wrap it inside a
> ResultSetDynaClass)
>1d. Push the original Connection, Statement, and ResultSet onto a
> request context "stack" of some kind (with an agreed-upon key name).
> 2. JSP page does the following:
>2a. Iterate through the ResultSet (or it's wrapper) as if it were a
> standard collection of standard beans.
> 3. Filter does the following cleanup:
>3a. Retrieve the "stack" of open JDBC primitives from the request
> context.
>3b. Close them all.
> 
> This seems to achieve a nice level of zero-copyness without bothering
> the JSP page with messy plumbing details. Comments?
> 
> Thanks,
> Bryan
> 

Re: Zero-copy persistence with Struts?

[V. Cekvenich]

Look at basicPortal.sf.net, we use rowSet, not resultset.
.V

Bryan Field-Elliot wrote:

I'm banging my brain against the sides of my skull trying to think of a
way to do zero-copy JDBC persistence with Struts.

What I mean by zero-copy is, basically, pass as much "raw data" as
possible between the Model layer and the View layer. In pragmatic terms,
this probably means taking a JDBC ResultSet in the Model layer,
decorating it somehow (e.g. wrapping it in a DynaBean, or otherwise),
and setting it into the Request attribute context, where the JSP page
can iterate through and display it.

Why bother? Performance.

So here's the catch... if I insert the ResultSet into the request
context, then somewhere later I need to close the ResultSet, and
probably also the Statement which produced it and possibly even the
Connection which was queried in the first place. It wouldn't make sense
from a design standpoint to put this plumbing in each JSP page.

My thinking is to build a Filter (Servlet 2.3) which, after all Model
and View classes are called (e.g. Struts actions and JSP pages), close
all the ResultSets, Statements, etc. This seems a little complex but
it's the best pattern I can come up with. I was hoping for some (expert)
opinions on this approach.

The basic flow would be:

1. Struts Action does the following:
   1a. grabs a connection from the pool
   1b. create a Statement (or PreparedStatement), do the JDBC work,
obtain a ResultSet
   1c. Decorate the ResultSet as needed (e.g. wrap it inside a
ResultSetDynaClass)
   1d. Push the original Connection, Statement, and ResultSet onto a
request context "stack" of some kind (with an agreed-upon key name).
2. JSP page does the following:
   2a. Iterate through the ResultSet (or it's wrapper) as if it were a
standard collection of standard beans.
3. Filter does the following cleanup:
   3a. Retrieve the "stack" of open JDBC primitives from the request
context.
   3b. Close them all.

This seems to achieve a nice level of zero-copyness without bothering
the JSP page with messy plumbing details. Comments?

Thanks,
Bryan






--
To unsubscribe, e-mail:   
For additional commands, e-mail: