EJB design: EJB vs CCM

  1. EJB vs CCM (8 messages)

    Dining Philosopher is a common example in the CCM world, with 3 components Philosopher, Fork and Observer. I intend to reconsider and approach this example by the EJB model. The Fork will be an Entity Bean; the Observer will be a Message Driven Bean. As for the Philosopher, it seems to be difficult to model. Could you guys help me or recommend me something on that?.

    Threaded Messages (8)

  2. Dining Philosophers[ Go to top ]

    I'd have a SLSB controller that creates SFSB's for the forks and the philosophers, and sets the number of forks to the sum of the philosophers minus 1. Philosophers have four states: thinking, eating and sleeping, and time elapsed. Getting hungry is a derived state. The fork is either used or not. Observer, as you suggest, would be an MSB.

    I wouldn't have the forks as entities unless:
    a) It is important to have entities somewhere
    b) It is acceptable to configure the philosophers (SFSB's) around the number of forks (I believe that the original Dijkstra problem technically had it the other way around)
  3. Dining Philosophers[ Go to top ]

    I use Fork as entity because I'd store the info (the property isUsed ) of the Fork in database.
     If your fork is a SFSB, you can store thi info of each Fork inside the bean. Here there is the problem of 2 philosopher use the same Fork, it mean 2 client request the same Session Stateful Bean. So how do you manage this in the EJB container?
  4. Fork handle[ Go to top ]

    Each philosopher can only reference one fork. This is a very simple model, so I'd picture each one them with a handle to the appropriate fork. What I'm trying to avoid is the situation where you have an entity (fork) with only one persistent attribute (isUsed) and which only lasts the lifetime of the session anyhow (the meal).
  5. Fork handle[ Go to top ]

    The problem is each philosopher reference not only one fork but two fork, and 2 near philosopher share the fork who is between them. So your solution seem to cannot solve this situation. That why I have chosen entity for the for even dispite it contain only one persistent field + one key.
  6. left and right fork[ Go to top ]

    Each philosopher needs two implements. Usually this is a knife and fork or two chopsticks. Two forks is a variant I haven't come across before, but I suppose it must work the same way. So instead of having one handle to a fork, and a corollary handle to a knife, there would be a right handle to a fork and a left handle to a fork.
  7. BTW[ Go to top ]

    BTW the dining philosophers problem is illustrative, and so the solution I have outlined may not be best for your purposes. If you want to illustrate how session, entity, and message beans can be applied to the problem then it would make sense to use entity beans as forks. I suppose you could then go further (as a more advanced topic) and remodel the state as session state with SFSB forks and handles.

    And a further topic beyond that might be the poor scaleability of SFSB's. Too many forks, and it can be more optimal to use entities.
  8. BTW[ Go to top ]

    Hi there, I have tried your solution, it still exist the situation of 2 philosopher use the same Fork, I mean the problem of 2 client request the same stateful bean. it seems the container does not manage the synchronization of request. It throw the Exception : SessionBean is executing another request.
    My version of entity is running well :-)
  9. Doh[ Go to top ]

    Ah yes - A handle can be shared by multiple clients, but the session bean that it represents can only be executed by one client at a time. I can't think of a way round this in the Dining Philosopher problem, because the container is forbidding exactly the sort of concurrent access (among philosphers) that the problem models in the first place.

    I therefore agree that you would have to use entity beans to avoid the container's handling of the concurrency issue.