This discussion is archived
5 Replies Latest reply: Mar 15, 2011 5:44 AM by YoungWinston RSS

Domain design causing full object graph serialization

560990 Newbie
Currently Being Moderated
Hello,

I work on a project, based on 3-layer-architecture. We have rich client developed on swing, application server and we persist our domain objects in the database.

We map the domain objects using hibernate, send the same objects (means, we use POJOs and don't use DTO) via spring from application server to the server and visa versa in case the objects are to be saved, deleted etc.

We use an object identity store on the client side, in which all already loaded objects are stored.

My challenge is as follows:

- Since an object is stored in the object store, the same certain object is used in every GUI module. Imagine, we have customer, account and a list of transactions per account. In practice, let's say:

1 customer
2 accounts
1000 transactions per account which ever exist

- In one of the modules, the used loaded all list of transactions. So, at that moment, 1 customer object, 2 accounts and 2000 transaction objects are bound to each other via java references (object graph).

- On another module, the user wants to edit a very small attribute of customer object, say he corrects his birthday date and saves it.

- Saving operation sends the customer object to the server. But the problem is, a very big object graph hangs on this one little customer object and are serialized to the server, although the
service.save(customer);
is called, and this costs extremely much time for our application.


boldSOLUTION:*bold* We solved the problem with a hack, as we used the serialization over XStream framework from Thoughtworks in xml-format. We could set a cut in the serialization and have serialized only the customer object for that use case.

So the problem for the save-use case was solved. This has a disadventage: the loading time (server-client (de-)serialization) using xml is longer than the java standard, especially remarkable if you load a big number of objects.

I've read many articles about the enterprise architectures which are related to domain objects, dto, serialization. It is not uncommon to avoid DTOs and use POJOs on the server and client as well, if the domain objects don't contain business logic. So, I just wonder, how the problem above should be solved smartly, if the non-DTO, say POJO alternative is chosen.

I appreciate your opinions.
I hope my question is not too long. Thanks in advance,


A sample code:
(The concrete case in our application requires the navigability from customer to account)
public class Customer implements Serializable {

     private Set<Account> acounts = new HashSet<Account>();

     // Getters, setters

}


public class Account implements Serializable {

     private Set<AccTransaction> acounts = new HashSet<AccTransaction>();

     // Getters, setters

}

public class AccTransaction implements Serializable {

     private String operation;

     private Timestamp timestamp;

     // Getters, setters

}
Alper
  • 1. Re: Domain design causing full object graph serialization
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Is 2000 a realistic size estimate or just something that you wildly guessed at?

    And do you have 100,000 customers that are that big or only 1?
    Did you actually attempt to send a data model with 2000 records and so that is why you know it is too expensive or are you just guessing?

    Other than that you shouldn't be using one model for every operation. If you have a requirement to update just a date then your database layer should have functionality to support just that and nothing else.
  • 2. Re: Domain design causing full object graph serialization
    560990 Newbie
    Currently Being Moderated
    Thanks for the quick answer.

    The numbers are just wildly guesses, in order to keep the sample simple.

    Actually we develop a system for automobile industry. So, instead of customer, you may think of a company, like Ford. Account would be then Fiesta. Instead of AccTransaction we may think a huge number of car pieces (clima, motor, radio, etc.).

    So hierarchically we have

    Company (Ford, Opel, etc)
    Model (Fiesta, Astra, etc.)
    Piece (1000 pieces per model, so Fiesta, Opel have 1000 different pieces each)

    The problem is, if I loaded the Ford->Fiesta->1000x pieces for one view and then switch to another view. In the second view, I rename Fiesta to Fiesta II, and want to save this renaming operation using:
    service.saveOrUpdate(model);
    , than the whole object graph of Ford->Fiesta->1000xpieces is sent (serialized) to the server.

    If I set a cut, say:
    model.setPieces(null);
    service.saveOrUpdate(model);
    the pieces of the model are deleted, since I have a strond boundary piece->model, and therefore cascade="save".

    I wonder how this problem is solved smartly, if you guys share domain objects between the client and server, and avoid DTO.
  • 3. Re: Domain design causing full object graph serialization
    560990 Newbie
    Currently Being Moderated
    Is 2000 a realistic size estimate or just something that you wildly guessed at?
    In the car model, it is realistic and it costs much, according to the tests and practice.
    And do you have 100,000 customers that are that big or only 1?
    Let's say, all of the car model models have similar number of pieces attached. The the expensive rule is valid for all.
    Did you actually attempt to send a data model with 2000 records and so that is why you know it is too expensive or are you just guessing?
    It does cost much time, in practice.
    Other than that you shouldn't be using one model for every operation. If you have a requirement to update just a date then your database layer should have functionality to support just that and nothing else.
    So you mean, I shouldn't use cascade="save" for the parent-child relationships?
  • 4. Re: Domain design causing full object graph serialization
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    acelik wrote:
    Thanks for the quick answer.

    The numbers are just wildly guesses, in order to keep the sample simple.

    Actually we develop a system for automobile industry. So, instead of customer, you may think of a company, like Ford. Account would be then Fiesta. Instead of AccTransaction we may think a huge number of car pieces (clima, motor, radio, etc.).

    So hierarchically we have

    Company (Ford, Opel, etc)
    Model (Fiesta, Astra, etc.)
    Piece (1000 pieces per model, so Fiesta, Opel have 1000 different pieces each)

    The problem is, if I loaded the Ford->Fiesta->1000x pieces for one view and then switch to another view. In the second view, I rename Fiesta to Fiesta II, and want to save this renaming operation using:
    What exactly does that represent?

    If you want to rename an existing car then you need logic to do exactly that. You do not copy the entire tree.
    If however you do want to copy the entire tree then that is in fact what you must do. Although I seriously doubt that there is a valid business requirement for that. In terms of efficiency though you could write a proc that did that rather than propogating the tree.

    Although further if you do in fact have two cars which use the same inventory item(s) then, again, you do not copy the entire tree because you are not creating a brand new inventory item. Instead you should only be pointing to an existing item.
    I wonder how this problem is solved smartly, if you guys share domain objects between the client and server, and avoid DTO.
    The first step is to start with actual business requirements.
  • 5. Re: Domain design causing full object graph serialization
    YoungWinston Expert
    Currently Being Moderated
    acelik wrote:
    So you mean, I shouldn't use cascade="save" for the parent-child relationships?
    It depends, as jschell says, on the business requirements; however, what you're doing (or at least enforcing in this instance) does sound like overkill to me. I suspect, though, that the problem lies more on the fetching side than the saving one.

    If you are, indeed, simply renaming a model, and you want that change reflected across the entire system, then it strikes me that it's a simple name change, and I think you're probably hamstringing yourself by uploading the entire model structure every time you want to do something to a model.

    On the other hand, if the name is used as a primary key, you may well have a problem (and perhaps some modeller's head should roll).

    Winston

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points