Re: RMI and Proxied collections and references

[Tomasz Wysocki]

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?

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".

So transportable proxies can use whatever c/s mode is currently in use, servlets, ejbs or plain sockets?

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.

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.

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".

"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.

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 forgot about JCS. Only thing bad about it, it has so many config-options ;-). Is there an updated tutorial on using it with OJB?

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?

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?

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.

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.

Thanks for many insights, that were troubling me from some time now.

Tomasz Wysocki



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]