Design question - long transaction


EJB programming & troubleshooting: Design question - long transaction

  1. Design question - long transaction (3 messages)

    Hey, My client is a swt client that runs on machine A and the server is a J2ee server that runs on machine B. We use facade design pattern and the API are exposed to the client as a stateless session bean. The user does some configuration changes. for change (like add new components ... ) we need to go to the server in order to create or edit the component (the client doesn't have the knowledge how to do this) in the end of the configuration process the user may press on the persist button and all the changes need to be persist. The concept that i need to implement is similar to the concept of editing word document all the changes are saved in temporal document until the user click on save or close the document. As I see it I need long transaction here, but stateless doesn't support in long transaction and there are a lot of problems (time out and etc) in a long transaction. I have to save those "temporal configurations" to the DB, because I need to get id for these configurations and other operations. Does any one have an idea how to implement it? It is important to remember that if the user edit an existing component other user don't see those changes unless he press on the save button. This scenario can lead to conflict. Thank you. Any idea will be welcomed.
  2. Try to use stateful session beans to accumulate changes (in the editing process) and then insert them in DB in one short transaction (like Save button in Word editor). Maybe it'll be useful in your case.
  3. relation between objects. i dont want to ude statfull because i want to expose my API as a stateless.
  4. If you want to use stateless ejbs you need to track data changes in DB yourself. It's like long-running business process' state. BPM solutions track states of process' in DB. But in this case you need to mantain integrity (other users don't see changes, etc) yourself whith rather complex logic.