Hi again <snip> > Ok. Again a couple of questions :) > > 1. How does the server and client communicate ? (RMI, raw > tcp/ip, or ?)
we have currently two implementations: 1. A Servlet 2. A TCP/IP Socket server. This server is build like and http server but just supports a different protocol. See http://jakarta.apache.org/ojb/clientserver.html > 2. Any thoughts on how to avoid keeping a transaction alive ? We have to differentiate between PersistenceBroker transaction (which are backed by a JDBC-transaction) and ODMG transaction which are logical object level transactions. A PB tx is always bound to a specific JDBC transaction. thus keeping it open for a long time is expensive. A ODMG transaction does only need a PB Transaction during its commit() operation. Thus having an ODMG tx open for 5 weeks is no problem. > I think what I want is the concept of "Long transactions" > AND that it can > be "controlled" by any session bean. The ODMG spec does not say anything about long transactions. thus we did not implement them yet. But this is already on the todo list for our OTM based refactoring of our ODMG and JDO implementations. > e.g. I do not want to have a generic PersistenceBrokerBean > which a client > can call and "misuse" :) > > <snip> > > > It's possible to prevent remote clients from accessing a > broker by sending > > them objects that have no proxies inside. (by setting > proxy="false" on > > reference- and collection descriptors) > > > > I already checked in the support for > > PersistenceBroker.retrieveReference(instance, > attributeName) to allow > > explicit loading of references and collections ! > > Great - And I have already asked for more :) You will ask yourself: is the todo list a stack or a queue? cheers, Thomas > /max > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
