I may not understand your description correctly but it sounds like you are under the impression that adding remote interfaces to your EJBs will inherently give them the capability of automatically synchronizing their data over multiple JVMs and servers - it does not. In regards to your situation you may want to ponder the following points:
First Law of Distributed Object Design: Don't distribute your objects! (Martin Fowler, PEAA p.89). So your application itself should be designed so that it is stateless. If there is any state necessary, identify the smallest possible subset and attach this "data-context" to every message between the client and the server. Of course, there are cases where this "context" can become too large.
Avoid giving entity java beans a remote interface - use a Session Facade instead. Once you design the session facade you may find that you really don't need the entity beans anymore.
Avoid using stateful session beans if you can. If it is necessary to maintain state between the client and the server, maintain that state in an HttpSession in the web tier. HttpSessions are easier to migrate from one server to another when necessary.
While on an API level local and remote interfaces may look very similar - they do exist for totally different reasons. The local interfaces are used for finer-grained interfaces between domain objects that reside on the same server but may want to take advantage of some of the EJB container's services (otherwise they should simply be POJOs). The remote interfaces are used for coarse-grained interfaces; much less like an object interface but more like a service interface (that uses an entire domain model to process a request). So, if you are looking at an enterprise bean that exposes the same interface locally and remotely then you are most likely looking at an inappropriate design.