Hello Rickard,
Thank you for this so quick answer.
...
> load-balancing or fail-over?
> Net yet, will be soon.
...
> Not yet, will be soon.
...
> No, no yet.
OK, so I will have a look at the todo list to see when it should happen.
...
> Yes, the bean bindings you do in java:comp/env can either be to local
> beans in your local server, or to beans running on some other (central)
> server.
OK but my problem is not only in the bean location. It is also in the JNDI
naming location. If the JNDI graph is located on a server, it is no more
possible to reach it for local query (when disconnected).
Some times ago, I've managed this (I was using CORBA and Java, no EJB, ...)
by having a Naming service hosted centraly AND on each station. So each
station had stored locally its own stuff and when it wanted to reach server
information it was transparently linked to another naming service through a
distant NamingContext CORBA object (mesh of naming services or federation of
naming services, depending...) So this was a good start. The problem was
that I was unable to have access to distant object information when
disconnected which could help sometimes.
In this federation of NS possible with JNDI with distant namingContext
possible?
> There is no notion of synchronization, but this is an application notion
> that you could accomplish anyway. For example, let's say you have an
> EntityBean both "locally" and in your central server. First you do local
> changes. Then you want to synch that with the server. You should then
> have some session bean in your local server which you can tell "I am now
> connected. Synch this local EntityBean with the central server's
> EntityBean". The session then extracts state from the local EntityBean
> and applies it on the server, either by modifying existing bean
> identities, or by creating/removing on the server. You will need some
> kind of log locally to keep track of what changes to propagate.
ok for the state sync part.
> So, in short, yes that kind of application is possible (and I would be
> *very* interested in hearing about the results!), but most of the stuff
> is application specific so you would have to do it by yourself.
OK. thank you for your help. Cheers,
Sacha
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
