ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris O'Connell" <oconn...@gorillachicago.com>
Subject RE: Transaction Performance Issue
Date Thu, 10 Apr 2008 14:52:09 GMT
I'm a little confused by this.  Is this some sort of asynchronous process
where the user clicks a button and it causes a message to get dropped on a
queue (for example) which causes the system to execute this bit of work as
quickly as it can?  If this is the case, then you *do* have a pending stage.
>From the time the user clicks their button to the time the back end system
gets a chance to execute that request, "pending" seems like the only word
that describes the situation.

The other possibility is that I have confused something and that this is a
synchronous process.  The user clicks a button and this does a "post" to a
web server which executes the code you have shown us and then renders a page
to the user saying "Congratulations".  The user is then clicking another
button and trying to view a page with the updated data and what they see is
not the updated data.  Is this what is happening?

Or (sorry if I seem to be making things more complicated), are you in a case
where the user hits the 'Submit' button and the browser starts doing its
work and before the user gets a response, they get impatient and quickly
click another button on the page (perhaps the 'View My Profile' button) and
they are then taken to the 'My Profile' page.  Now, we have a race condition
where the user sent two different requests to your system (I'm assuming that
this is a web application), and if the second request ("Show me the profile
page") executes before the first request ("Update my profile") then the user
sees old data.

I don't see how the second possibility is possible.  The only thing I can
imagine is that somewhere in your system something has cached the results of
a query and you are getting this cached result.  

The third case seems possible (but unlikely).  If it is the third case, you
could try to do a little user training on your page.  Either put up a
message that says "This is the real world.  Things do not happen
instantaneously.  Give me a chance to finish before you click another
button." (or something like that).  Or, perhaps you use a little javascript
to disable all the other buttons on the page as soon as the user clicks the
'Update my Profile' button.  Then, they don't have any choice except to wait
for the system to execute their request.

Hopefully I haven't gone too far from what you are really experiencing...

-----Original Message-----
From: Vannel [mailto:vadriewyn@hotmail.com] 
Sent: Wednesday, April 09, 2008 8:18 PM
To: user-java@ibatis.apache.org
Subject: Re: Transaction Performance Issue


the problem lies in the fact that my program cannot afford to have a
"pending" stage. changes made have to be instantly visible to the user. in
fact, the user is not at fault since he could say, update his home address,
then click on the update button and then immediately go to the page where he
is able to view the updated details. the flow there is not wrong. but
somewhere in between there seems to be a slight problem. i actually got a
return from the database, which brings me to think the SQL has been
successfully run. however, it seems like when i get the return, the actual
data in the db has not been updated/commited, which i find wierd. i have
tried playing around with the transactionmanager in iBATIS as well, making
sure all SQLs are commited even if i was playing with CRUD statements only.
daoManager.commitTransaction() doesn't seem to solve my problem either after
some extensive testing.

anyway, if anyone else any suggestions, please do post. i think i might ask
on an Oracle forum instead and see what suggestions i get.
-- 
View this message in context:
http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16599708.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 4/9/2008
4:20 PM
 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 4/9/2008
4:20 PM
 


Mime
View raw message