You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Vannel <va...@hotmail.com> on 2008/04/09 12:26:56 UTC

Transaction Performance Issue

Hi,

I have a performance issue i'm not sure how to solve effectively. Here's my
situation..
I'm trying to run INSERT/UPDATE/DELETE statements and using their return
values as confirmation that the statement has been duly completed by my db
(Oracle).

---

e.g. 
<update ...>UPDATE table1 SET field = #value# WHERE idfield =
#idvalue#</update>

int confirmation = update(...)
//upon getting confirmation, send out an alert to the user
if (confirmation > 0) {...send out alert...}

---

the problem lies here. if the user (for example) refreshes his UI
immediately after sending the UPDATE, a small fraction of the time, the
change will not be reflected yet. unfortunately, my program requires me to
have 100% assurance that the user will be able to notice the change.

does anyone have any suggestions? i suspect it might be an issue with how
Oracle handles SQL since i am able to get a positive return from it. could
it be an issue with how iBATIS works?
-- 
View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16583884.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


Re: Transaction Performance Issue

Posted by Vannel <va...@hotmail.com>.
im using EJB as my external transaction manager
-- 
View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16739622.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


Re: Transaction Performance Issue

Posted by Brandon Goodin <br...@gmail.com>.
If you are using an external transaction manager it is completely up to you
to manage the transactions. iBATIS utilizes the connection that is handed to
it by your external transaction manager. What is the external transaction
manager that is being used?

Brandon

On Thu, Apr 17, 2008 at 12:41 AM, Vannel <va...@hotmail.com> wrote:

>
> can anyone tell me what the scope of a transaction is?
>
> -----
>
> try {
>  //execute sql
>  int ret = insert(...);
>
>  if (ret>0) {
>    //execute some other sql
>    update(...);
>  }
> }
> catch {
>  //catch errors
> }
>
> -----
>
> in the above scenario, are there 2 transactions (1 for insert, 1 for
> update)..? or is it considered 1 transaction within a try-catch? if i am
> using an external transactionmanager, where does the commit come in? i
> don't
> have anything in my EJB that controls transactions. In this case, how is
> iBATIS handling the commits?
> --
> View this message in context:
> http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16739287.html
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>

Re: Transaction Performance Issue

Posted by Vannel <va...@hotmail.com>.
can anyone tell me what the scope of a transaction is?

-----

try {
  //execute sql
  int ret = insert(...);
  
  if (ret>0) {
    //execute some other sql
    update(...);
  }
}
catch {
  //catch errors
}

-----

in the above scenario, are there 2 transactions (1 for insert, 1 for
update)..? or is it considered 1 transaction within a try-catch? if i am
using an external transactionmanager, where does the commit come in? i don't
have anything in my EJB that controls transactions. In this case, how is
iBATIS handling the commits?
-- 
View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16739287.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


Re: Transaction Performance Issue

Posted by Alistair Young <al...@gmail.com>.
On 11/04/2008, Vannel <va...@hotmail.com> wrote:
>
>  Sorry about not being clear. Initially I was trying to give an example and in
>  the later post I decided to give a more accurate representation of my
>  program. I dont think I am using any form of caching unless it's on by
>  default. To be abit clearer, my client receives notification right after the
>  update(). However, the client is unable to see the updated information
>  immediately. Only after some delay of a few seconds will the client be able
>  to see the update.
>

Hi Vannel,

iBATIS caching has to be switched on manually in your SQL map
configuration, so I guess it's not likely to be that.

All I can think to suggest is to put some debug code into your
application so that you can see when the database update has been made
(i.e. after the call to the update() function, but before you notify
the client), and when the client is requesting the data (i.e. in your
'get' method).  The only thing that really makes sense is if your
client is requesting the data before the update() has finished - i.e.
before the notification has been issued.

So, I don't think that the problem is with iBATIS - but perhaps with
the general flow in your application?  If you want to rule out iBATIS
to your own satisfaction, you could try issuing SQL statements
directly - then it will be absolutely clear what is happening when.


Alistair.

Re: Transaction Performance Issue

Posted by Vannel <va...@hotmail.com>.
Sorry about not being clear. Initially I was trying to give an example and in
the later post I decided to give a more accurate representation of my
program. I dont think I am using any form of caching unless it's on by
default. To be abit clearer, my client receives notification right after the
update(). However, the client is unable to see the updated information
immediately. Only after some delay of a few seconds will the client be able
to see the update.
-- 
View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16627288.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


Re: Transaction Performance Issue

Posted by Alistair Young <al...@gmail.com>.
Hi Vannel,

As I understand it, iBATIS will issue each of your SQL statements
(select, update) to the database in turn.  However, the "return" (I
assume you mean the result of the update() call) will only happen once
both statements have been executed.

I'm still a bit confused as to what your application is doing - in an
earlier e-mail you talked about the user pressing an 'Update' button,
but here you talk about another process making the update.

Also, is the problem that sometimes the user never sees the result, or
is it that sometimes it takes longer than expected?

Are you using any caching in iBATIS?

Cheers,


Alistair.

On 11/04/2008, Vannel <va...@hotmail.com> wrote:
>
>  your 2nd scenario fits my situation alot more. synchronous process. what
>  happens is that i have a client machine listening to changes within the db
>  and updates the client realtime. as an admin, i was sending in sample data
>  into the db via my own terminal. sometimes happens that the client gets, for
>  example, a popup saying new data has been entered (notification is sent when
>  admin gets a return from db). however, the update is not displayed on the
>  client side until a few seconds later. i was wondering about the db caching
>  the SQL and the result as well, but i was wondering if iBATIS had anything
>  to do with the process. would i be mistaken if i assumed the whole SqlMap
>  gets executed and returned as 1 entity? or does iBATIS break up each SQL
>  statement in the SqlMap and handle each SQL individually?
>
>  ---
>
>  <sqlmap ...>
>  select field1 from table1 where field2 = value2
>  update table1 set field3 = #value3# where field1 = value1
>  </sqlmap>
>
>  int confirm = update(...)
>
>  ---
>
>  in the above situation, would there be a return from the select statement
>  AND another return from the update statement? or, would there only be 1
>  return after the whole sqlmap has been completed?
>
> --
>  View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16624028.html
>
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>

RE: Transaction Performance Issue

Posted by Vannel <va...@hotmail.com>.
your 2nd scenario fits my situation alot more. synchronous process. what
happens is that i have a client machine listening to changes within the db
and updates the client realtime. as an admin, i was sending in sample data
into the db via my own terminal. sometimes happens that the client gets, for
example, a popup saying new data has been entered (notification is sent when
admin gets a return from db). however, the update is not displayed on the
client side until a few seconds later. i was wondering about the db caching
the SQL and the result as well, but i was wondering if iBATIS had anything
to do with the process. would i be mistaken if i assumed the whole SqlMap
gets executed and returned as 1 entity? or does iBATIS break up each SQL
statement in the SqlMap and handle each SQL individually?

---

<sqlmap ...>
select field1 from table1 where field2 = value2
update table1 set field3 = #value3# where field1 = value1
</sqlmap>

int confirm = update(...)

---

in the above situation, would there be a return from the select statement
AND another return from the update statement? or, would there only be 1
return after the whole sqlmap has been completed?
-- 
View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16624028.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


RE: Transaction Performance Issue

Posted by Chris O'Connell <oc...@gorillachicago.com>.
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
 


Re: Transaction Performance Issue

Posted by Vannel <va...@hotmail.com>.
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.


Re: Transaction Performance Issue

Posted by Alistair Young <al...@gmail.com>.
On 09/04/2008, Vannel <va...@hotmail.com> wrote:
>
>  Hi,
>
>  I have a performance issue i'm not sure how to solve effectively. Here's my
>  situation..
>  I'm trying to run INSERT/UPDATE/DELETE statements and using their return
>  values as confirmation that the statement has been duly completed by my db
>  (Oracle).
>
>  ---
>
>  e.g.
>  <update ...>UPDATE table1 SET field = #value# WHERE idfield =
>  #idvalue#</update>
>
>  int confirmation = update(...)
>  //upon getting confirmation, send out an alert to the user
>  if (confirmation > 0) {...send out alert...}
>
>  ---
>
>  the problem lies here. if the user (for example) refreshes his UI
>  immediately after sending the UPDATE, a small fraction of the time, the
>  change will not be reflected yet. unfortunately, my program requires me to
>  have 100% assurance that the user will be able to notice the change.
>
>  does anyone have any suggestions? i suspect it might be an issue with how
>  Oracle handles SQL since i am able to get a positive return from it. could
>  it be an issue with how iBATIS works?
>
> --
>  View this message in context: http://www.nabble.com/Transaction-Performance-Issue-tp16583884p16583884.html
>  Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>
>

I'm not sure exactly what you mean by "sending out an alert" - but
maybe you could get around your problem by setting the text to be
displayed to "CONFIRMATION PENDING" or somesuch before the update is
executed, so that if the user refreshes his UI (a browser, I'm
guessing) before you're ready, at least they will get some indication
that what they can see isn't the whole story.  Unless you've got some
server-push capabilities, I guess there's always a risk that a page
will be rerendered before you're ready.

I doubt it's an iBATIS issue.  Sounds more like "annoying users doing
things in the wrong order to me" :).


Alistair.