Hi folks,

I have a quick design question for you, I would appreciate
any feedback you could give me.

Our applications requires the user to create dynamic 'views'
of data. For example, the user can create a 'view' that consists of column 1 from table X, and colum 3 and 4 from table Y. Because of the dynamic nature of these views, we
have decided not to use Entity beans (because we are only
interested in certain columns of data, from many tables).

Instead of the EJB approach, we generate our own SQL based
on the view, and have a Session bean perform the query for us, and generating the ResultSet containing the data.

The problem we have run into with this approach is this:

Once the Session bean has created the ResultSet, we have
to somehow get it over the network back to the client.

Our 1st solution was to extend Sun's CachedRowSet, but
the time to serialize/de-serialize a large CachedRowSet
takes far too long.

Out 2nd solution was to parse the ResultSet into String
object as an XML document. Serialization is MUCH faster,
but now we have run into a problem of parsing the ResultSet
on the server, and converting the XML representation on the client to something meaningful.

If anyone can give me any insight as to how we could get better performance, either using Entity beans, or by any
other means, I really appreciate it.

> the time to serialize/de-serialize a large CachedRowSet
> takes far too long.
Did you try a normal Vector or Collection for this?

> Out 2nd solution was to parse the ResultSet into String
> object as an XML document. Serialization is MUCH faster,
Don't do this because String is really heavy for the network.

The next question is: Do you need all the rows at one time? Or maybe your client program just needs 30 rows at one time? So you can make a call like this from the client to your Session Beans:

public Vector findView(int startIndex, int count) throws ... {
...
}

So every time you call, you also pass the startIndex and the count value. This will keep the rows that you need to transport to the client compact.

Lofi.

> the time to serialize/de-serialize a large CachedRowSet
> takes far too long.

> Did you try a normal Vector or Collection for this?

I'm not sure what you mean here. Parse the ResultSet into
a Collection of some sort, and attempt to serialize that
informatation instead of the CachedRowSet?

> Out 2nd solution was to parse the ResultSet into String
> object as an XML document. Serialization is MUCH faster,

>Don't do this because String is really heavy for the network.

How can a String of text be 'really heavy' for network traffic? Can you clarify this? I don't see how serializing a Collection could be faster than a String?

>The next question is: Do you need all the rows at one >time? Or maybe your client program just needs 30 rows at >one time? So you can make a call like this from the client >to your Session Beans:

>public Vector findView(int startIndex, int count) >throws ... {
>...
>}

>So every time you call, you also pass the startIndex and >the count value. This will keep the rows that you need to >transport to the client compact.

We're currently using Stateless session beans, in order to do the above, we would have to change to Stateful beans, which come at some kind of performance hit I'm assuming.
(The Session bean would have to perform the query, and keep
it around until the client has consumed all the records).

I appreciate your opinions, I hope you can anwer the few questions I've raised here.

Glenn

Lofi.

If the underlying data is relatively stable, then you can reissue the query each time and grab the needed rows. This would require the data to be stable over the average pageview time (say 2 minutes or so) I've done this with a search engine type of functionality. We carried the query in a hidden field. As long as the user can't do a search within, you should be fine.

Yes. Since Collection or Vector is much more compact (no necessary attributes to serialize like for CachedRowSet). This also means, that your data will be sent through the network with fewer bytes.

> How can a String of text be 'really heavy' for network
> traffic? Can you clarify this? I don't see how serializing
> a Collection could be faster than a String?
I mean, if you put all the XML tags in your String, this can blow up your String's size. If you use Collection or Vector you don't need to put all these XML tags.

> We're currently using Stateless session beans, in order to
> do the above, we would have to change to Stateful beans,
Nope. I also use stateless session beans. I also try to prevent using stateful session beans. Look at my example system OpenUSS (http://openuss.sourceforge.net): http://pcwi012.uni-muenster.de
The faculty list I show there using this kind of design. I'll upload the 1. Version of OpenUSS next week. Here is the sample code:

/**
   * Finds all active faculties. This method
   * should be used for all things about the faculty.
   * This method also use start point and count for the result.
   *
   * @return vector of facultys.
   * @param startIndex, count.
   * @exception RemoteException, FinderException.
   */
  public java.util.Vector findActiveFaculties(int startIndex, int count)
    throws RemoteException, FinderException {
    // Get the home interface from faculty
    // and make a new vector
    FacultyHome home = (FacultyHome)HomeInterfaceFactory.create(
      FacultyHome.class, FacultyHome.COMP_NAME);

    Vector facultyList = new Vector();

    // Get all !!!active!!! faculties
    Enumeration facultyEnumeration = home.findActive();
    Faculty facultyState;
    FacultyObject facultyObject;

    // Skip initial rows as specified by the startIndex parameter.
    while (startIndex > 0 && facultyEnumeration.hasMoreElements()) {
      facultyEnumeration.nextElement();
      startIndex--;
    }

    // Continue to loop and fill the vector as needed with count
    while (count > 0 && facultyEnumeration.hasMoreElements()) {
      // Get the EJBean
      facultyObject = (FacultyObject)facultyEnumeration.nextElement();

      // Fill the state object to save it
      // into the vector
      facultyState = new FacultyState(facultyObject.getPrimaryKey().toString());
      facultyState.setActive(facultyObject.getActive());
      facultyState.setName(facultyObject.getName());
      facultyState.setOwner(facultyObject.getOwner());
      facultyState.setRemark(facultyObject.getRemark());

      facultyList.addElement(facultyState);

      // Decline count
      count--;
    }

    // Return the vector
    return facultyList;
  }

You also can look this at Sun's pet store example.

Hope this help!

---------------------------------------------------
Blasius Lofi Dewanto
---------------------------------------------------
OpenUSS - Open University Support System
http://openuss.sourceforge.net
---------------------------------------------------
E-Mail : [email protected]
ICQ : 39343280
---------------------------------------------------

Ups wrong url! Here is the right one: http://pcwi012.uni-muenster.de:9000
The "9000" is the port for Enhydra ;-)

Lofi.

Based on your above implementation, do you have any idea what the performance difference would be from the XML implementation? We would have to do the following for each call:

- execute query
- manipulate the ResultSet to get the rows we are interested in (startIndex -> count).
- Create some type of Row object for each object being added to the Collection.
- The Row object would be composed of a Collection of Column objects, in order to store the data type of the column etc.
- Plus anything I'm not thinking of at the moment ;)

This seems like a lot of overhead when comparing it to the speed of XML parsers that are available right now.

The XML approach would look something like this:
- execute query
- parse ResultSet to an XML representation.
- Send XML (wrapped as a String object) back to the client.

It seems to be a lot more effecient to do it the XML way.

Comments/Suggestions?

Interesting,XML is designed for interopertability not for
effeciency.

> - execute query
> - parse ResultSet to an XML representation.
> - Send XML (wrapped as a String object) back to the
> client.
But this means that you'll send all of the result from your query through the network. And this can be very "heavy".

Let's say you also use "startIndex" and "count" and afterwards you parse the ResultSet to an XML representation. This is ok, but as I told you:
- First you need to build the XML representation. This takes much more memory than just creating some java objects and put it together in a collection.
- Second you will also have to send the XML tags within your object.

I don't think that using XML to send the object is more efficient than using normal java objects.

But if you want to do so, you can look at the Zeus project from Enhydra. http://zeus.enhydra.org/index.html
With Zeus you can transfer a java object to its XML representation back and forth. This means you can transfer your XML document first to a java object and send it through the network. At the other end you can transfer it back again to XML if you want to. Or just transfer your java object to the XML document at the server and send it through the network and you'll get an XML object at your client.

This project looks really good and of course Open Source! ;-)

Have fun!

Lofi.