Isn't what we need a "Session" split in 2? Take the Hibernate Session code: some features need to be in the client VM, others on the Application Servlet, and the client Session needs to act as a proxy for those?

"Application Server" that is, not "Servlet". Sorry.

Well that sounds like a dream. So essentially maintaining the hibernate proxies over a rmi connection. It will automatically go back to the server whenever the proxies are accessed, reattach itself to it's original session and then go ahead and fulfill the request.

Sounds great but i think it is just a dream. Plus if something like this really existed imagine all the chatter that would occur. What i mean by chatter, is instead of preloading all the necessary data you will go ahead and get it lazily utilitizing hibernate to it's fullest. However in a client server app this translates to a million back and forth calls which kills performance. So in addition to the above requirements you also need to somehow have some type of transaction management on the client so the remote calls are clustered.

If this is something that is available or in the works fill me in and I will be all over that bandwagon.

that is called EJB 2 Entity Beans. feel free to use that ;)

Well, no, not really.

Actually, it would be nice to use this forum to brainstorm about how this split should be done. Please storm with me.

A first attempt:

First of all, I am going for minimal functionality for now. So: CRUD.


Reading:
----------
For reading, we want lazy loading. How about this:

In the client session, we have a call get(Class clazz, Serializable id) , which will "Return the persistent instance of the given entity class with the given identifier, or null if there is no such persistent instance. (If the instance, or a proxy for the instance, is already associated with the session, return that instance or proxy.)" Thus, obviously, the client session will have "associations", a map, of persistent objects delivered already. If the required instance is not in this map, it will call its remote (server) alter ego, which will get it from the DB for us. It comes to the client serialized, but without lazy collections. Before the client session hands over the object to the user, the lazy collections are initialized with local stubs. When these are accessed, the client session will again contact the remote session for the collection. This is fetched, in its entirety, and send to the client, serialized. The objects retrieved are again cached in the client session before handing them to the client. I believe that this will not put undue strain on bandwith: you get what you want, when you need it.


Writing:
---------
Here, we need update(Object object) on the client session. This will serialize the object, and send it to the remote session for storing. Obviously, the problem we have to face here is cascade. This functionality exists in the current Hibernate implementation, and thus has to be moved to the client. Especially dirty-detection is necessary.




Ok. Opinions, extensions, … please

Probably it doe's not make sence to use "client/server" session, you can implement JDBC driver wrapper using RMI and deploy hibernate on client (http://rmijdbc.objectweb.org/). As I understand it is more usefull to have "smart" serialization and lazy loading for entities returned by remote application methods.
It can be implemented using custom proxy serialization and using stateful session beans with client transactions to make it safe.
1) Implement statefull bean:

public interface Loader extends Remote {

Object initialize(Object handle);


}
2) Implement replacement object for serialization:

public class UninitializedEntity implements Serializable{

Object handle;

Object readReslove()throws ObjectStreamException{
return createProxy( handle );//CGLIB stuff to call "Loader" for remote initialization;
}

}


3) Implement custom persister to replace default proxy serialization

4) Use client transactions:

//servlet filter example
void doFilter( ... ){
InitialContext context = new InitialContext();
UserTransaction transaction = context.lookup("UserTransaction");
transaction.begin();
Loader loader = createRemoteBean(Loader.class);
//cache statefull bean in thread local variable

chain.doFilter(request,response);

transaction.commit();

//handle exception and release resources, close context, remove loader

}

I don't get it. Please elaborate. Isn't this a very complex way to just get Client/Server, with the classic Hibernate Session on the client? Aren't we loosing all the benefits of the app server in 3-tier this way?

This kind driver can be used as bridge for distributed transactions and authentication (connection to database and transactions are manged by container), it is a trivial way if hibernate is not too heavy for client.
It must be better to use callback to load lazy objects, but it is not trivial to implement this stuff if you need transactions. It looks like rmijdbc uses plain RMI and it needs wrapper for transction support too (Remote Connection implementation must be a stateful bean, but it must be trivial to wrapp rmijdbc).

But still, I am correct in understanding that the client would access the DB directly, without going through the App Server with such a solution?

Application server is connected to database, client/server communication is RMI. I do not recomment to use this way, it just an idea. I prefer "hard" way, custom serialization (I believe it is more secure)

Still don't get it, sorry.

Could you please elaborate on the pseudo-code you posted a 2 days ago,on the "smart" serialization (1-2-3-4)? Could you add some comments there, explaining what each method/type is intended for?

I have some dead code to solve similar issue, I can refactor it and create wiki page with initial implementation if you are going to test and to finish it yourself.

Well this is my exact problem. I am shocked that it has gone so long without answer. :(

I do not need remote lazy loading. I simply need the hibernate collections to be replaced with java collections before I send the object across the wire. I don't understand the problem with this?

Calling Hibernate.initialize is going to cause hibernate to change its collections for java collections??

To be perfectly honest, all I need is the hibernate collections and all classes used by the collections in a seperate jar. I suppose I can do that myself if I examine the classes.