tracking fast changing state in ejb tier.

Discussions

EJB design: tracking fast changing state in ejb tier.

  1. tracking fast changing state in ejb tier. (3 messages)

    I have a design problem regarding keeping track of state.

    Assume the following:

    the old sensor system layout. many sensors, one server. sensors report measurements and status to server at non-determenistic intervals.
    example: sensor A reports over time 5,6,3,4,8,2 and sensor B reports 3,4,5,6,7,8,9,2,4,3,2,1.
    No sequence, no identical number of reports from each sensor.

    want to be able to check state/status of all sensors at will, that is, a client request state/status from server and it should display the last reported state/status for every sensor. Example, sensor A=5, sensor B=7

    client is both java app and web client.
    So sensor state lives on common tier, ejb tier.
    Assume updates to state/status are so frequent that using entity bean is not practical. state/status might be updated several times a second. would entity still work?

    Storing sensor state/status in JNDI context might be too slow too. How would one synchronize updates? if state/status kept in HashMap, after every update, map has to be rebound to context. no other updates can be allows while it is being updated. How would one work around this?

    Stateful bean doesn't work, as only one stateful bean would have the state machine. there can be multiple clients which can't share the bean, pluss the state is updated by another server component, which would have it's own stateful bean.

    Singelton isn't good either. How would one ensure that all clients accessing would get the same singelton? considering multiple classloaders and JVMs. Distributed singelton would face concurrency problems. correct?


    Has anyone faced this problem and conquered it? How would you attack this problem?

    hope someone can help with ideas.
    thanks
  2. How many clients do you need to support? If your number of clients is relatively small, you would best off keeping everything on one machine/JVM, and sticking with the singleton approach.

    If you have to support a huge number of clients, but are able to tolerate a certain degree of inaccuracy in your data, you can create a read-only BMP entity whose ejbLoad() method only queries the database every minute or so. That way you can cluster, but your database read operations are relatively infrequent, and you can probably get reasonable performance.

    You can improve this by storing the sensor reports in the database with a timestamp, so that your BMP entity can be optimized to pull out only the information accumulated since its last read operation.

    You might also look at one of a variety of data-clustering packages, such Tangasol's Coherence.
  3. talking about data-clustering packages:

    How slow/fast would a solution where the statemachine and its operations were part of a remote object. This object could just be bound to the JNDI context and looked up across a cluster.
    RMI itself doesn't have to be that slow assuming one uses coarse-grained interface and possibly making DTO objects externalizable instead.

    Assuing this works, how does failover work (if the JVM that bound the object goes down)? Is this covered by some spec or would it be vendor specific.
  4. You have no fail-over unless (a) your data is in the database or (b) your data is clustered.

    If you want high performance, remote access to your statemachine is a problem. It means that you have two networks hops (client to EJB, EJB to statemachine) for every operation, with all of the associated latency.

    These are all very complicated problems to solve, and if you really need this level of functionality, you are better off looking for a data-clustering product that serves your needs rather than trying to build something from scratch.