Question on ServerObject (store)

[bade]

Hi all,

I was wondering if anybody knows if the serverobject is created once per session (or user if you will) or once only (load of datasource)?

And when is this serverobject ever destroyed (or garbage collected)?

In the DMI example of Smart GWT EE showcase the "store" keeps a hashmap with all the fetched data, we want to use this same system but if this serverobject is created only once (for each datasource and all sessions)... we need to rethink some stuff.

Thanx!

[Isomorphic]

The lifecycle depends on the "lookupStyle" used, for example, "new" creates a new object each time, but "spring" means that we're asking Spring for the bean, and so lifecycle management can be done in Spring configuration.

In that particular sample, the state that is being held onto is held in a static variable, so it's one per Java VM regardless of how serverObject works.

[bade]

In that particular sample, the state that is being held onto is held in a static variable, so it's one per Java VM regardless of how serverObject works.

Indeed, we followed the DMI example to the letter... but knew the static map had to go someday. So today is the day and now we are running into several problems.

The biggest problem is how to keep "state" and couple it to the session?
Is there a way of doing this using the server object?

Also, I don't seem to understand why the DS operations aren't called on the same server object that was created for a particular session? I understand that lookupStyle="new" create a new server object every time... but I thought that somehow it would be reused for the same session.

Any ideas? Thanks a lot!

[Isomorphic]

You don't want to follow the SupplyItemStore.java part of that sample "to the letter". Wherever you see a call in SupplyItemDMI to SupplyItemStore, that's where you would be using a real ORM system, such as Hibernate, to save.

In this case you should not need any servlet session state to achieve saving, and in fact, keeping a bunch of session state around is bad practice which hinders performance.

[bade]

Well, the good thing of the example was that it would save some roundtrips to our own persistence system.

The second thing (and part of the problems I'm now having) is that the update operation only gets the "updated" values and not all the values, that's why we liked the example, 'cause using the DataTools to sync with the values we had in the map (filled by the fetch) we could then (whenever the user decides to save/delete/whatever) just get ALL values from the map and save to our persistence system.

So, it still is kinda strange that the serverobject itself is not coupled to a session and is recreated every time. I'm just wondering how other projects, that work with multiple users, are handling this.

[Isomorphic]

You really want to get away from this pattern, it is a serious performance problem. Please do some background reading on proper use of session state in large scale and clustered applications if you're unsure.

As far as the complete values, they are always included in the request as dsRequest.oldValues.

[bade]

I understand... thanks for the answer, I have changed my implementation, using the oldValues.