ofbiz database connection , minerva ???
Locked
 
|
Hi everyone
We are test running our production site with JMeter test and multiple users, orders... and we are having trouble with DB connections (as below) , it seems to appear when some orders are created? config : Postgres 8.0.3 and 8.1, sequoia 0.8.3 we have a few ideas maybe someone has a real experience to share with us ? - we noticed when the server swaps this seems to cause more errors ? - we seem to have numerous deadlocks , has any have some experience with such errors ? (even with entity engine config as pool-deadlock-maxwait="300000" pool-deadlock-retrywait="10000" pool-minsize="200" pool-maxsize="200") - Minerva was pulled out of the new version of Sequoia, is this correct and why ? should we swap it ? - Is Geronimo a solution for replacing Minerva, I thought it was only a container ? Any help on this would be more than welcome Best Regards Tibor I read a few threads about the errors below but precise answer Can't get an XAConnection 52788 (invoker-Thread-7) [ ObjectPool.java:632:ERROR] Exception in creating new object for pool java.lang.RuntimeException: Could not create connection 52793 (invoker-Thread-7) [ ConnectionFactory.java:65 :ERROR] ---- runtime exception report -------------------------------------------------- There was an error getting a Minerva datasource. Exception: java.lang.RuntimeException Message: Could not create connection |
|
|
Tibor,
Minerva was replaced by the Geronimo transaction managers in ofbiz back in May of this year, but opentaps 0.9 still uses JOTM for transaction management. The next version of opentaps should incorporate the newer transaction manager currently used by the SVN version of OFBiz. The reason this was done was actually for licensing reasons, not for any technical reasons that I'm aware of. I think the problem you are experiencing may be more related to PostgreSQL than to the transaction manager layer of opentaps and OFBiz. Even OFBiz 3.0 and 3.1, which are a year older than opentaps 0.8.3, could be scaled up with the right configuration of the database. At some volume of connections, though, PostgreSQL would have to be clustered. Have you checked whether PostgreSQL is still running successfully? Si On Sep 29, 2006, at 8:02 AM, tibor katelbach wrote: > Hi everyone > > We are test running our production site with JMeter test and > multiple users, > orders... and > we are having trouble with DB connections (as below) , it seems to > appear > when some orders are created? > config : > Postgres 8.0.3 and 8.1, sequoia 0.8.3 > > we have a few ideas maybe someone has a real experience to share > with us ? > > > - we noticed when the server swaps this seems to cause more errors ? > > > - we seem to have numerous deadlocks , has any have some experience > with such errors ? > > (even with entity engine config as pool-deadlock-maxwait="300000" > pool-deadlock-retrywait="10000" pool-minsize="200" pool- > maxsize="200") > > - Minerva was pulled out of the new version of Sequoia, is this > correct and why ? should we swap it ? > > > - Is Geronimo a solution for replacing Minerva, I thought it was > only > a container ? > > Any help on this would be more than welcome > Best Regards > Tibor > > > I read a few threads about the errors below but precise answer > > Can't get an XAConnection > > 52788 (invoker-Thread-7) [ ObjectPool.java:632:ERROR] > Exception in > creating new object for pool > java.lang.RuntimeException: Could not create connection > > 52793 (invoker-Thread-7) [ ConnectionFactory.java:65 :ERROR] > ---- runtime exception report > -------------------------------------------------- > There was an error getting a Minerva datasource. > Exception: java.lang.RuntimeException > Message: Could not create connection |
|
|
Hi Si
Thanks for your answer. we are going soon into production so this subject is quite boyling hot. > I think the problem you are experiencing may be more related to > PostgreSQL than to the transaction manager layer of opentaps and > OFBiz. Even OFBiz 3.0 and 3.1, which are a year older than opentaps > 0.8.3, could be scaled up with the right configuration of the > database. would you have an optimum Postgres configuration sample by any chance I could see ? At some volume of connections, though, PostgreSQL would > have to be clustered. our limit amount of users 50 simultaneous with 1000 orders that's when the system starts slowing down (nice numbers :-) but we loose about 10% of orders. Have you checked whether PostgreSQL is still > running successfully? well I couldn't say if it's optimal, but we do have good results put appart the benchmarking and load testing. but when we load test, we get frequent deadlocks (coming from XAConnection or Postgres DB) as you can see in the logs below this is quite frightning "Process 7948 waits for ShareLock on transaction 5856857; blocked by process 7966." on SQL statement "SELECT 1 FROM ONLY "public"."contact_mech_purpose_type" x WHERE "contact_mech_purpose_type_id" = $1 FOR UPDATE OF x" before insert (from logs below) I would love an clear descritption of what is going on behind this ? do you know of a tool to debug PostGres ? and it's connections ? do you know a tool to follow Minerva connections ? other than the Verbose ? Thanks a lot for any help that can help us go forward cause we are stagnating a bit. Regards Tibor a few of our Postgres logs 2006-09-29 17:32:57 CEST 172.29.7.30(44627) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" 2006-09-29 17:32:57 CEST 172.29.7.30(44627) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.ORDER_ADJUSTMENT(ORDER_ADJUSTMENT_ID, ORDER_ADJUSTMENT_TYPE_ID, ORDER_ID, ORDER_ITEM_SEQ_ID, SHIP_GROUP_SEQ_ID, COMMENTS, DESCRIPTION, AMOUNT, AMOUNT_PER_QUANTITY, PERCENTAGE, PRODUCT_PROMO_ID, PRODUCT_PROMO_RULE_ID, PRODUCT_PROMO_ACTION_SEQ_ID, PRODUCT_FEATURE_ID, CORRESPONDING_PRODUCT_ID, SOURCE_REFERENCE_ID, SOURCE_PERCENTAGE, CUSTOMER_REFERENCE_ID, PRIMARY_GEO_ID, SECONDARY_GEO_ID, EXEMPT_AMOUNT, TAX_AUTH_GEO_ID, TAX_AUTH_PARTY_ID, OVERRIDE_GL_ACCOUNT_ID, INCLUDE_IN_TAX, INCLUDE_IN_SHIPPING, CREATED_DATE, CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27, $28, $29, $30, $31, $32) 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD production INSERT waitingERROR: deadlock detected 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD production INSERT waitingDETAIL: Process 7983 waits for ShareLock on transaction 5856663; blocked by process 7898. Process 7898 waits for ShareLock on transaction 5856853; blocked by process 7983. 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.POSTAL_ADDRESS(CONTACT_MECH_ID, PERSONAL_TITLE, TO_NAME, ATTN_NAME, ADDRESS1, ADDRESS2, DIRECTIONS, CITY, POSTAL_CODE, POSTAL_CODE_EXT, COUNTRY_GEO_ID, STATE_PROVINCE_GEO_ID, POSTAL_CODE_GEO_ID, PHONE_NUMBER, EMAIL, COMMENTS, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20) 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD production INSERT waitingERROR: deadlock detected 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD production INSERT waitingDETAIL: Process 7898 waits for ShareLock on transaction 5856901; blocked by process 7874. Process 7874 waits for ShareLock on transaction 5856663; blocked by process 7898. 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."payment_method_type" x WHERE "payment_method_type_id" = $1 FOR UPDATE OF x" 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.ORDER_PAYMENT_PREFERENCE (ORDER_PAYMENT_PREFERENCE_ID, ORDER_ID, PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, SECURITY_CODE, PRESENT_FLAG, OVERFLOW_FLAG, MAX_AMOUNT, PROCESS_ATTEMPT, BILLING_POSTAL_CODE, MANUAL_AUTH_CODE, MANUAL_REF_NUM, STATUS_ID, CREATED_DATE, CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19) 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD production INSERT waitingERROR: deadlock detected 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD production INSERT waitingDETAIL: Process 7874 waits for ShareLock on transaction 5856857; blocked by process 7966. Process 7966 waits for ShareLock on transaction 5856901; blocked by process 7874. 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."contact_mech_purpose_type" x WHERE "contact_mech_purpose_type_id" = $1 FOR UPDATE OF x" 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.PARTY_CONTACT_MECH_PURPOSE (PARTY_ID, CONTACT_MECH_ID, CONTACT_MECH_PURPOSE_TYPE_ID, FROM_DATE, THRU_DATE, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD production INSERT waitingERROR: deadlock detected 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD production INSERT waitingDETAIL: Process 7948 waits for ShareLock on transaction 5856857; blocked by process 7966. Process 7966 waits for ShareLock on transaction 5856900; blocked by process 7948. 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.POSTAL_ADDRESS(CONTACT_MECH_ID, PERSONAL_TITLE, TO_NAME, ATTN_NAME, ADDRESS1, ADDRESS2, DIRECTIONS, CITY, POSTAL_CODE, POSTAL_CODE_EXT, COUNTRY_GEO_ID, STATE_PROVINCE_GEO_ID, POSTAL_CODE_GEO_ID, PHONE_NUMBER, EMAIL, COMMENTS, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20) 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD production INSERT waitingERROR: deadlock detected 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD production INSERT waitingDETAIL: Process 7966 waits for ShareLock on transaction 5856987; blocked by process 7951. Process 7951 waits for ShareLock on transaction 5856857; blocked by process 7966. 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."payment_method_type" x WHERE "payment_method_type_id" = $1 FOR UPDATE OF x" 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD production INSERT waitingSTATEMENT: INSERT INTO public.ORDER_PAYMENT_PREFERENCE (ORDER_PAYMENT_PREFERENCE_ID, ORDER_ID, PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, SECURITY_CODE, PRESENT_FLAG, OVERFLOW_FLAG, MAX_AMOUNT, PROCESS_ATTEMPT, BILLING_POSTAL_CODE, MANUAL_AUTH_CODE, MANUAL_REF_NUM, STATUS_ID, CREATED_DATE, CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19) |
|
|
Tibor,
50 simultaneous users placing 1000 orders at the same time? We should all be so lucky. This does sound like a problem I used to have when we were running on a server which could not handle the capacity. Basically postgresql got slow with all the requests, creating a deadlock, and thus the problems. So I do suspect the problem is with postgresql and not with ofbiz or the transaction manager. If you want to "prove" it scientifically, maybe you can have postgresql log all the SQL statements and then try feeding it just the SQL statements to see what happens. Unfortunately I don't know PostgreSQL nearly well enough to recommend an "ideal" configuration. Craig and Matthew at Contegix are very knowledgeable, and I've basically relied on them for all the database and server configuration stuff. Good luck. Sorry I'm not more helpful. Si On Oct 4, 2006, at 9:58 AM, tibor katelbach wrote: > Hi Si > Thanks for your answer. > we are going soon into production so this subject is quite boyling > hot. > > >> I think the problem you are experiencing may be more related to >> PostgreSQL than to the transaction manager layer of opentaps and >> OFBiz. Even OFBiz 3.0 and 3.1, which are a year older than opentaps >> 0.8.3, could be scaled up with the right configuration of the >> database. > > would you have an optimum Postgres configuration sample by any > chance I > could see ? > > > At some volume of connections, though, PostgreSQL would >> have to be clustered. > > > our limit amount of users 50 simultaneous with 1000 orders > that's when the system starts slowing down (nice numbers :-) but we > loose > about 10% of orders. > > Have you checked whether PostgreSQL is still >> running successfully? > > > well I couldn't say if it's optimal, but we do have good results > put appart > the benchmarking and load testing. > > but when we load test, we get frequent deadlocks (coming from > XAConnection > or Postgres DB) > as you can see in the logs below this is quite frightning "Process > 7948 > waits for ShareLock on transaction 5856857; blocked by process 7966." > on > SQL statement "SELECT 1 FROM ONLY > "public"."contact_mech_purpose_type" x > WHERE "contact_mech_purpose_type_id" = $1 FOR UPDATE OF x" before > insert > (from logs below) > > I would love an clear descritption of what is going on behind this ? > do you know of a tool to debug PostGres ? and it's connections ? > do you know a tool to follow Minerva connections ? other than the > Verbose ? > > Thanks a lot for any help that can help us go forward cause we are > stagnating a bit. > Regards > Tibor > > a few of our Postgres logs > 2006-09-29 17:32:57 CEST 172.29.7.30(44627) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" > 2006-09-29 17:32:57 CEST 172.29.7.30(44627) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.ORDER_ADJUSTMENT(ORDER_ADJUSTMENT_ID, ORDER_ADJUSTMENT_TYPE_ID, > ORDER_ID, ORDER_ITEM_SEQ_ID, > SHIP_GROUP_SEQ_ID, COMMENTS, DESCRIPTION, AMOUNT, AMOUNT_PER_QUANTITY, > PERCENTAGE, PRODUCT_PROMO_ID, PRODUCT_PROMO_RULE_ID, > PRODUCT_PROMO_ACTION_SEQ_ID, PRODUCT_FEATURE_ID, > CORRESPONDING_PRODUCT_ID, > SOURCE_REFERENCE_ID, SOURCE_PERCENTAGE, CUSTOMER_REFERENCE_ID, > PRIMARY_GEO_ID, SECONDARY_GEO_ID, EXEMPT_AMOUNT, TAX_AUTH_GEO_ID, > TAX_AUTH_PARTY_ID, OVERRIDE_GL_ACCOUNT_ID, INCLUDE_IN_TAX, > INCLUDE_IN_SHIPPING, CREATED_DATE, CREATED_BY_USER_LOGIN, > LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, > CREATED_TX_STAMP) > VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, > $14, $15, > $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27, $28, > $29, $30, > $31, $32) > 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD > production INSERT waitingERROR: deadlock detected > 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD > production INSERT waitingDETAIL: Process 7983 waits for ShareLock on > transaction 5856663; blocked by process 7898. > Process 7898 waits for ShareLock on transaction 5856853; blocked by > process 7983. > 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" > 2006-09-29 17:33:00 CEST 172.29.7.30(44659) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.POSTAL_ADDRESS(CONTACT_MECH_ID, PERSONAL_TITLE, TO_NAME, > ATTN_NAME, ADDRESS1, ADDRESS2, > DIRECTIONS, CITY, POSTAL_CODE, POSTAL_CODE_EXT, COUNTRY_GEO_ID, > STATE_PROVINCE_GEO_ID, POSTAL_CODE_GEO_ID, PHONE_NUMBER, EMAIL, > COMMENTS, > LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, > CREATED_TX_STAMP) > VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, > $14, $15, > $16, $17, $18, $19, $20) > 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD > production INSERT waitingERROR: deadlock detected > 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD > production INSERT waitingDETAIL: Process 7898 waits for ShareLock on > transaction 5856901; blocked by process 7874. > Process 7874 waits for ShareLock on transaction 5856663; blocked by > process 7898. > 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."payment_method_type" x WHERE "payment_method_type_id" = > $1 FOR > UPDATE OF x" > 2006-09-29 17:33:03 CEST 172.29.7.30(44574) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.ORDER_PAYMENT_PREFERENCE (ORDER_PAYMENT_PREFERENCE_ID, > ORDER_ID, > PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, SECURITY_CODE, > PRESENT_FLAG, > OVERFLOW_FLAG, MAX_AMOUNT, PROCESS_ATTEMPT, BILLING_POSTAL_CODE, > MANUAL_AUTH_CODE, MANUAL_REF_NUM, STATUS_ID, CREATED_DATE, > CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, > CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, > $7, $8, $9, > $10, $11, $12, $13, $14, $15, $16, $17, $18, $19) > 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD > production INSERT waitingERROR: deadlock detected > 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD > production INSERT waitingDETAIL: Process 7874 waits for ShareLock on > transaction 5856857; blocked by process 7966. > Process 7966 waits for ShareLock on transaction 5856901; blocked by > process 7874. > 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."contact_mech_purpose_type" x WHERE > "contact_mech_purpose_type_id" > = $1 FOR UPDATE OF x" > 2006-09-29 17:33:06 CEST 172.29.7.30(44550) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.PARTY_CONTACT_MECH_PURPOSE (PARTY_ID, CONTACT_MECH_ID, > CONTACT_MECH_PURPOSE_TYPE_ID, FROM_DATE, THRU_DATE, > LAST_UPDATED_STAMP, > LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, > $2, $3, > $4, $5, $6, $7, $8, $9) > 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD > production INSERT waitingERROR: deadlock detected > 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD > production INSERT waitingDETAIL: Process 7948 waits for ShareLock on > transaction 5856857; blocked by process 7966. > Process 7966 waits for ShareLock on transaction 5856900; blocked by > process 7948. > 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."geo" x WHERE "geo_id" = $1 FOR UPDATE OF x" > 2006-09-29 17:33:09 CEST 172.29.7.30(44624) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.POSTAL_ADDRESS(CONTACT_MECH_ID, PERSONAL_TITLE, TO_NAME, > ATTN_NAME, ADDRESS1, ADDRESS2, > DIRECTIONS, CITY, POSTAL_CODE, POSTAL_CODE_EXT, COUNTRY_GEO_ID, > STATE_PROVINCE_GEO_ID, POSTAL_CODE_GEO_ID, PHONE_NUMBER, EMAIL, > COMMENTS, > LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, > CREATED_TX_STAMP) > VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, > $14, $15, > $16, $17, $18, $19, $20) > 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD > production INSERT waitingERROR: deadlock detected > 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD > production INSERT waitingDETAIL: Process 7966 waits for ShareLock on > transaction 5856987; blocked by process 7951. > Process 7951 waits for ShareLock on transaction 5856857; blocked by > process 7966. > 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD > production INSERT waitingCONTEXT: SQL statement "SELECT 1 FROM ONLY > "public"."payment_method_type" x WHERE "payment_method_type_id" = > $1 FOR > UPDATE OF x" > 2006-09-29 17:33:12 CEST 172.29.7.30(44642) PROSODIE_ECOMMERCE_PROD > production INSERT waitingSTATEMENT: INSERT INTO > public.ORDER_PAYMENT_PREFERENCE (ORDER_PAYMENT_PREFERENCE_ID, > ORDER_ID, > PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, SECURITY_CODE, > PRESENT_FLAG, > OVERFLOW_FLAG, MAX_AMOUNT, PROCESS_ATTEMPT, BILLING_POSTAL_CODE, > MANUAL_AUTH_CODE, MANUAL_REF_NUM, STATUS_ID, CREATED_DATE, > CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, > CREATED_STAMP, CREATED_TX_STAMP) VALUES ($1, $2, $3, $4, $5, $6, > $7, $8, $9, > $10, $11, $12, $13, $14, $15, $16, $17, $18, $19) Best Regards, Si [hidden email] |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |