Jon, Essentially you are struggling with the age old short vs. long transaction model. In a world of unlimited computing resources, you could start the transaction on the client, and interact with the Entity Beans through remote interfaces. This might work in a small scale application with low concurrent users and high network bandwidth. However most folks looking at EJB are not in this category (we can leave these applications to MS Access ;-) In the short transaction model, you have to break your problem down into shorter user units of work. Instead of the typical client server "wander around and do anything you want until you press the commit button", you should break the user interface down into as discreet interactions as possible. Each discreet interaction should represent a separate short transaction. If there is a bigger complex business transaction, comprised of many little steps, you could commit the discreet updates to a 'staging area' until the final transaction is completed. At that point the server can apply all the small pieces of work in one larger piece of work, but in a short time span. Depending on the requirements a work flow environment may be of assistance here. <vendor> We are holding a seminar on design practices for J2EE systems at http://netseminar.com/ tomorrow. This will cover several design issues, and to some degree the area you have raised. This is pretty generic distributed system design stuff, and should be useful to both GemStone and non GemStone customers. There is still time to register in the morning before it starts. </vendor> Regards, -Chris. > -----Original Message----- > From: Jon Tirsen [SMTP:[EMAIL PROTECTED]] > Sent: Monday, December 13, 1999 2:05 PM > To: [EMAIL PROTECTED] > Subject: Simulations and entities, or, "where to put your > business-logic". > > A little problem with transaction and persistent objects like entities: > > Picture this: > An application is accessed by some means of asynchronous device such as a > web-browser (suprise!). Therefor one does not want to start a "physical" > transaction for each "gui" transaction. Where "gui" transaction is a > user-experienced transaction, like for example a dialog box with "OK" and > "Cancel" buttons. The reason for this is that "physical" transactions > takes > up too much resources and probably will have timeout a couple of zeros > away > from what a user experiences as a good timeout. > Ok, this is no surprise. I bet we're all working this way under these > conditions. > The solution is an application of the probably most famous design patterns > of EJB so far. The "Session as a facade to Entity"-pattern. We cache the > state of the "gui" transaction in a SessionBean (could also be the some > objects associated with http-session). When the user presses "OK" the > "physical" transaction is started and the data is flushed into the > entities. > Or something like this, there are probably as many variants of as there > are > ejb-architects. > > Ok, here comes the problem. > > What if the user was editing some kind of complex entity consisting of > various values and options with relations and constraints binding them all > together. When the user edits the entity he would like to interactively > see > the result of editing the values. If he feels satisfied with the editing > he > "commits" the "gui" transaction, if he's not he "rolls it back". > If the calculations are complex they would want to be implemented using > the > oo-niceties of the EntityBeans but there is a problem. Since the > entity-beans are by definition transactional and persistent if the > session-bean facade edited the fields and read back the result (ie. > performed a "simulation" hence the subject) a transaction would be started > and the "simulation" would be commited, which was not at all what the user > wanted. > The way to get around this is to put the "business-logic" in the > session-bean and perform the calculations on the "cached" data instead. > But > suppose the calculations is some kind of invariant, entity-specific > calculations and not (as we say it) process-specific (ie. related to the > session-bean facade), then the calculations has to be put on both places, > or > in a place where both could access it. In the last case it (and this is > where it gets really creepy) has to be put in some sort of "library", ie. > using functional decomposition (the oh-so infamous anti-pattern). > The other way is to simply use bean-demarcated transactions, start a > transaction, set it to rollback only, perform the simulation and roll it > back. But this also gives me a strange gut-feeling. (Although I've used > this > strategy before when working directly to database.) > > Ok, bean providers, how do you solve this, and, > container providers, what solution do you recommend (let me see those > <vendor>-tags :). > > Jon Tirs�n > Chief Architect > Itec Open Business Integrator AB > PGP key lookup: > http://certserver.pgp.com:11371/pks/lookup?op=get&search=0xE9032B9A << > File: Jon Tirs�n.vcf >> =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
