Hi again, Tomasz Wysocki wrote:
auto-retrieve="false" : the reference-attribute is not touched and remains null. If the reference-attribute is needed later it must be loaded explicitely by a call to PB.loadReference("attribute_name").Thomas Mahler wrote:The PB c/s mode has the same fine grained call structure as the singlevm PB. Currently there is no way to cut down the nuber of network calls for c/s mode. The only thing you can do is to change the "auto-retrieve" and "proxy" settings to change the granularity of loaded object graphs.Does auto-retrieve and proxy settings combine to produce meaningful results?
auto-retrieve="true", proxy="false" : load the reference-attribute and fill it with "real" data.
auto-retrieve="true", proxy="true" : don't load the real data, but fill the reference-attribute with a proxy.
So transportable proxies can use whatever c/s mode is currently in use, servlets, ejbs or plain sockets?
This is the most easy solution and would safe us a lot of work.
The big problem: it could result in transferring rather large object graphs to the client! The only remedy I see is some kind of "tranportable proxies".
correct!
I don't know how many windows are broken in c/s mode, cause I don't use it, and don't have any plans to do so.
all changes to PB API after 0.9.6 must be made accessible.
The c/s mode is already build that way. The server side component is just a simple delegation mechanism into a singlevm broker.
The whole idea of c/s mode seems OK, just like database servers are ok.
They can be clustered, they serve and cache data, provide synchronization and transaction management. So c/s mode is just like an object database.
correct, that was my initial idea. the only problem: it is a lot of work to maintain singlevm an c/s in parallel!
Here exposes my lack knowledge on OJB internals. But I think that it is a matter of refactoring to separate remote features such as invocation and cluster synchronization from core functionality, and not dropping such an amount of work already done. Then changes in core PB would not affect c/s mode build on top.
The rest is only prc infrastructure. For the socket server and for the servlet we have to implement the call mechanisms.
So it's not *that* much work. The worst thing is the test cycle. The complete Junit tests for PB take 20 minutes or so...
"remote" proxy behaviour should be than configured on class descriptor and collection basis not as global OJB option. Say, proxy="true|false" remote-proxy="true|false". Question is how big 'codequake' this will produce.But just like them, c/s mode is also an another tier, which may not be needed in a particular application, and would only impact the performance.
That's why I'm questioning the whole c/s mode. But I feel that we need some kind of "transportable proxies".
Won't be difficult to implement.
I forgot about JCS. Only thing bad about it, it has so many config-options ;-). Is there an updated tutorial on using it with OJB?The only thing lacking in this picture is a persistence cache implementation that would behave correctly when application is clustered, and that leads us to c/s mode or EJB Entity beans.
I don't agree here. OJB provides a JCS cache that may be clustered. ALso the optimistic and pessimistic locking features are ready for clustering even without c/s mode!
I'm not quite sure. But I think Matthew once posted a howto?
correct! For running the OMDG layer in a cluster we provide a Persistent LockMap that is maintained n a database table. (In SingleVM mode the lock Map is kept in memory).
Then at the second sentence c/s mode idea slipped me. How come that pessimistic locking == synchronization doesn't require a form of remote communication == c/s mode in clustered environment. Does it employ a db?
If the tx is committed we are lost, correct. But as long as we are running within the same server side tx everything is fine...
Maybe the PB SessionBean could be a solution:
if we are running container managed transactions (CTM) a remote proxy acesssing the PB SessionBean could act within the same server side transaction boundary as the main transaction.
I cannot see how would that be possible. After transaction was commited it was commited. And a new remote call to PB SessionBean from a remote proxy will begin a new transaction (if marked as 'Required'). Or am I missing an idea here?
I agree. One of OJB guidelines is to support POJOs and not require special user coded infrastructure (like VOs).There is a "value object" pattern that is used in those situations. This pattern we try to avoid, to lessen then burden of maintaining several model representations namely : db schema, business objects, value objects, html forms. It is a great advantage if business object are POJOs, and not some framework components.Looks like I'm demanding to much from OJB, but even EJB doesn't support such behaviour like returning Local Entity Beans as a result of a Remote Call.
Yes that's really a tough problem. But as several users faced this kind of problem we should provide a solution.
Thanks too. This discussion helped me to see clearer wrt. to the c/s mode and the remote proxy issue.Thanks for many insights, that were troubling me from some time now.
cu,
Thomas
Tomasz Wysocki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
