Re: Deadlocks in one of our apps
Re: Deadlocks in one of our apps
- Subject: Re: Deadlocks in one of our apps
- From: Chuck Hill <email@hidden>
- Date: Fri, 4 Jun 2010 09:27:46 -0700
On Jun 4, 2010, at 4:40 AM, Pascal Robert wrote:
...
- It's a (non public) online store. When people log in, we
create a order in memory and customers add order items to the
order. We don't store anything in the DB until the payment is
made with PayFlow. When we get the response from PayFlow, we
store a copy of the order (and the items) to our Oracle db.
After that, we contact our SQL Server db (actually, a
accounting system, and we send the data to a stored procedure),
and we get the invoice number produced by the accounting system
and store it in the order EO in Oracle.
So in summary :
- People login, we create a order EO, the EO is created in the
session's editing context
- People add items to the order
- They start the order payment steps
- Long response page kicks in
- We contact PayFlow to make the payment
- If the payment is succesful, we store the order in Oracle
- We create a new EO, in a different EC, for SQL Server
- We update the order EO to store the invoice number in Oracle
- We generate (FOXML, generated in a separated JVM) the
invoice in PDF
- Long response page is done, pageForResult is called
Everything is done in session.defaultEditingContext EXCEPT the
SQL Server EOs,
You are not using the session.defaultEditingContext in the long
response page, are you? I am pretty sure that is an excellent
source of deadlocks.
Hum, yes we do use in the long response page... But since
localInstanceOfObject won't let me have a copy in a new EC, what
are the options except not using the session EC?
Not using the session EC would be a good choice. Make a different
EC. Pass it into the long response page. Be careful handing off
locking.
You could also save the order in an "unpaid" state, then fetch it
in the long response page and update it if paid, or delete it if
not.
Ooh, yeah, you could do that too.
So we end up doing :
- before the long response page is called, we save the EO in a
unpaid state
- in the method called in performAction, we create a new editing
context, we lock it and we insert a copy of the order EO into the
new EC by using localInstanceOfObject
"we fault (not insert) a copy of the order EO into the new EC"...
Just everyone is clear on what is happening.
- the bulk of the job is done in a try {} finally { ec.unlock() }
- when the method that is called inside performAction have done his
job, the order EO is sent back
- we override the order EO that was stored in the session default
editing context with the one that was inserted in the temporary EC :
((Session
)session
()).setCommande
((Commande
)EOUtilities.localInstanceOfObject(session().defaultEditingContext(),
(Commande)copieCommande));
I'd put that move between ECs in Session:
public void setCommande(Commande c) {
command =
(Commande)EOUtilities.localInstanceOfObject(defaultEditingContext(),c);
}
and change the line above to
((Session)session()).setCommande(copieCommande);
That way the session is protected and does not rely on the client code
being correct.
So far, so good. We will see later today when the load get higher if
we get any deadlocks.
Many thanks to all who helped out :-)
Let us know how it works out!
Chuck
----
Pascal Robert
email@hidden
AIM: MacTICanada
Twitter : MacTICanada
LinkedIn : http://www.linkedin.com/in/macti
WO Community profile : http://wocommunity.org/page/member?name=probert
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden