Hi again, Tomasz Wysocki wrote: <snip>
Yes, you're right. C/S mode in this case would defer materialization further to the moment when client really needs data. However, in a distributed environment there is also a need to minimize number of trips to the server, to decrease the network overhead.I agree! That's why I said that c/s mode can cause problems if used carelessly. You will need some configuration tuning to make c/s apps performant. The biggest problem I see is access granularity.
In other words, configuration should provide means to change this behaviour, so it will match needs of particular application.
With a typical EJB session bean it is easy to define the granularity of remote access programmatically.
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.
So it would be code that could reside in the OJB proxy classes. User code won't be affected. cool!It is a proxy that serializes not a persistent object itself, so there is no special need to implement callbacks by application developer on persistent classes.
Yes, this could be an elegant solution! AFAIK there are some callbacks in the serialization api that could help to implement this trick.
Only disatvantage I see: persistent classes must be derived from a base class implementing these callbacks?
I was thinking about writeReplace rather than writeObject as Phil Warrick suggested. So say we have a CollectionProxy class that on serialization does materialize ArrayList and designates it to be its replacement in a stream.
This is the most easy solution and would safe us a lot of work.
Are you willing to work on this? I will review your stuff and integrate it into the codebase!
I don't have a code yet, just thoughts.BTW. I don't want to use c/s mode.
I see!
We are currently discussing to drop the c/s mode altogether. The only *real* benefit the c/s mode had was the support for network-enabled proxies.
If we can replace this feature with your solution the last reason for c/s mode has gone and we could drop it without problems!
As I see it, there are two approaches.
1. The whole object model is materialized and no further calls are made to the server.
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".
2. The proxies are transported as handles to a client side and materialize instances when client needs data. And those proxies are providing functionality resembling that of remote objects.
This is the current c/s mode solution: "transportable proxies"
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.correct, that was my initial idea. the only problem: it is a lot of work to maintain singlevm an c/s in parallel!
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.
From my perspective c/s mode combined with proxies is a form of replacement for remote EJB Entity Beans which provide the same functionality.
correct, that was my original idea!
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".
From what I've learned, using combination of EJB Session Beans and direct JDBC to access data is the most performant and robust solution in most cases. Then, I don't mind using a simple persistence layer that would isolate me from pecularities of a data storage, which PB API is really best for.
I agree. This approach works fine for most cases.
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!
Matthew Baird pointed out that tx handling in most appservers is done before serialization layer. Transaction commit will take place before a serialization will occur, which leads to one *main* transaction on remote call and then several transactions to materialize lazy objects, just before send to client. Still in some appliactions, it is better than serveral remote calls to retrieve those objects later.Maybe the PB SessionBean could be a solution:
This tx boundary problem arises from the fact that persistent objects are not managed by application server container, ( and we don't want them to be ). Only Jboss would be so flexible so that you could mess with EJB interceptor stack and invokers to perform serialization earlier than transaction handling, but surely this would impact other things.
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.
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.
It's not exactly a replacement. It's one of the c/s mode implementations. We currently have:
The idea of an EJB bean implementing PersistenceBroker interface seems like a replacement for c/s mode.
- a socket based PB server
- a PB servlet
- a PB Session Bean
All three components implement the PB interface.
cheers,
Thomas
Cheers Tomasz ;-) --------------------------------------------------------------------- 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]
