> > 3. When the objects (proxies) are serialized onto the client then the proxy > > has an internally reference to the > > persistence broker that "gave birth" to them - and this persistence broker > > is probably holding a reference to > > a connection to the database - That is NOT healthy in a 2/3-tier solution. > > Or have I misunderstood how it works ? > > The proxies are marshalle *without* the server-side broker. On the > client a Broker stub is used to access the server. Thus no > jdbc-connection related stuff is send to the client.
Ok - this is more healthy than my "nightmare"-description :) But how does the stub communicate with the server ? Via RMI, or ? Well - what I want is that the client CANNOT communicate silently behind the programmers back when he is "dotting"-around in the model. > > > 4. And in C/S mode the "client" also have a persistencebroker, right ? > > a PB stub only, that delegates all calls to the server-side PB. And this server-side PB is shared amongst clients ? Does it keep the connection "forever" ? > > Then > > the client suddenly can access the database without having the app.server as > > a middle-man ? > > There is a servlet based PB server implementation. thus it is possible > to have all jdbc-connection and transaction related stuff under full > control of the app server. Yes - and the servlet based stuff could probably be extended to be a session bean or similar. But - still the client would have more or less direct contact with the "database". I would like to have a layer between the client and the actual persistencemechanism....maybe a dream, but I think it is a necessary dream :) /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
