I have not used Ebean in a terminal server environment.

I'm thinking you a building rich-client (Swing/SWT) application. My long term plan/intentions for such applications was to develop a 3 tier architecture...

Swing/Swt/+EbeanClient <- http/tcp -> Ebean/Jetty/Tomcat <- jdbc -> DB

... which would then support "array fetching" between the "EbeanClient" and "Ebean on the app server". It would add client specific api to support batching multiple commands into a single request.

Anyway... that was what I'm thinking but that (EbeanClient) doesn't exist yet... so I'd describe a current Swing/SWT app using Ebean as 2 tier client/server.

.dictionary
--------------
Some information is determined from the DB meta data such as foreign keys etc so that Ebean can automatically guess the correct relationships rather than having to use @JoinColumn type annotations. The DB meta data can be slow to obtain from a DB... hence it is cached in the .dictionary file.

Yes I see your problem. Unfortunately Ebean is currently not optimal for a terminal server environment like what you have...

Hmmm... the .dictionary file could be considered/treated immutable assuming the DB does not change. So I'm thinking Ebean could change a little to treat the .dictionary file as immutable ... based on a flag or something....

Hmmm... trying to think what sort of behaviour you'd want around autofetch in a terminal server environment.

I have been thinking that Ebean could generate a xml file from the autofetch information which would serve as a 'starting position' for tuned queries. So Ebean would read that on startup (rather than a serialised file)... and if you turned off autofetch it wouldn't perform any further tuning. Aka you develop an autofetch.xml file during development... and then use that in production (but prod has autofetch turned off and doesn't perform any further tuning).

Hmmm... those are my thoughts... unfortunately I have not written a Swing/Swt Ebean app yet so "EbeanClient" has not happened ... perhaps it would not really help you either in your terminal server environment.

Hi!

Yes, I develop a two tier Swing application. Not sure about having a 3 tier implementation of Avaje ...

Both suggestions are fine for me and exactly what I thought.

Treating the dictionary as immutable and having an autofetch developed which then gets deployed sounds very good to me.
This might prohibit from having undesired behaviour in production if the atuofetch turned into the wrong direction ;-)

I think I'll have a look at that.

Thanks!

Ciao,
Mario

(Last post eaten due to session timeout during write?)

Would you mind if I extends DefaultResourceManagerFactory to
1) have a separate dir config for autofetch (defaulting to dictionary dir)

2) honor system properties like ${user.home} in the configuration?

That way I can start without the need to develop an autofetch.xml which might be a little bit too complicated.
You have to have 100% test coverage to be sure that the autofetch makes sense then.

>> (Last post eaten due to session timeout during write?)
Yeah - I need to look into and fix that - its a pain when you write a long post.

>> 1) have a separate dir config for autofetch (defaulting to dictionary dir)
Yes. That makes sense.

>> 2) honor system properties like ${user.home} in the configuration?
Ebean should already evaluate ${user.home} correctly in the ebean.properties file.

- Rob

>> 1) have a separate dir config for autofetch (defaulting to dictionary dir)
Yes - that makes sense.

>> 2) honor system properties like ${user.home} in the configuration?
Ebean already will evaluate ${user.home} in the configuration (so you should not need to do this).

- Rob.