Re: Deadlocks in one of our apps
Re: Deadlocks in one of our apps
- Subject: Re: Deadlocks in one of our apps
- From: Pascal Robert <email@hidden>
- Date: Fri, 4 Jun 2010 07:40:44 -0400
...
- 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
- 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));
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 :-)
----
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
_______________________________________________
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