 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | Subject: DAO, Entity CMP, Strategy | Subject: DAO, Entity CMP, Strategy 2004-09-28 - By Gerard Toonstra
Back
Didn't notice I replied directly, rather than to the list....
>Hi there,
>
>First of all, make sure you don't have a debugger remotely attached to the JVM
>and active breakpoints :) I don't think this is it however, so here goes:
>
>
>Are you stress-testing on the same entities?
>For instance, all tests for the same customer X?
>
>In that case it's very likely that you are causing a deadlock in the
>database, because
>you're working on rows in the tables that are related, but you access these
>rows from different transactions/threads. If you don't need this highly
>concurrent actions on exactly the same entity, I'd suggest changing the tests
>to work on different entities concurrently. That may solve your problem
>right here.
>
>
>If the deadlock is database related, some (most?) databases ( Oracle, Sybase )
>have facilities to get info about deadlocks. I know only how in Oracle.
>The best
>bet then is to:
>
>* Run the test
>* Wait for the deadlock to occur and ( for Oracle )
>* execute the following SQL's. You may need to login as SYS or have DBA
>role assigned:
>
>
>SQL> select * from v$locked_object;
>select object_name from dba_objects where object_id = .... ;
>
>For more info go to groups.google.com or consult the database documentation.
>
>
>If you do definitely need highly concurrent access on same entities and
>you cannot change
>code or there are no apparent ways to fix it, you *will* need to
>synchronize the access to
>the entities somehow. Ways of doing this are outside the scope of the
>topic. Another way
>is to divide the data somehow so that the concurrent access simply does
>not occur.
>
>
>Another thing I can think of is when you use "synchronized" in your code
>anywhere.
>Maybe thread A is trying to get access to a code block where thread B is
>currently
>executing in. When thread A holds exclusive access to a resource that
>thread B needs,
>thread B cannot complete the block and both threads will wait ( sometimes
>indefinitely,
>depending on the type of resource). If you do use "synchronized" anywhere,
>verify
>that you do not use resources that you have acquired before you executed
>the block, but
>acquire them within the block if you definitely need the resource access
>within the block.
>The worst here is a combination of "synchronized" blocks that are
>intertwined. The JVM,
>other than a database, will not detect these deadlocks and it will simply
>hang forever.
>
>
>Many deadlocks occur due to race-conditions. Therefore if you start
>looking for it through
>the use of a debugger, you may suddenly not encounter the deadlock at all
>because now you
>are changing the speed of execution of at least one of the threads. This is a
>good point to remember before you start debugging.
>
>Hope that helps,
>
>Gerard
>
>At 01:36 28/9/2004, you wrote:
>>Hi,
>>
>>In the code snippet of the DAO factory. The objects of DAO's are created
>>using SingleTon pattern.
>>But I have also doveloped the same factory and I asked the question that do
>>Is this the right design or it could create the bottelneck situation for the
>>application.
>>My application was getting hanged during stress testing. So, I raised this
>>question.
>>
>>Now, can you explain that is there any flaw when our application is going to
>>be used by simoltaneously users.
>>Your input is appreciable.
>>
>>Manish
>>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
<html>
<body>
<br>
Didn't notice I replied directly, rather than to the list....<br><br>
<br><br>
<blockquote type=cite class=cite cite="">Hi there,<br><br>
First of all, make sure you don't have a debugger remotely attached to
the JVM<br>
and active breakpoints :) I don't think this is it however, so here
goes:<br><br>
<br>
Are you stress-testing on the same entities?<br>
For instance, all tests for the same customer X?<br><br>
In that case it's very likely that you are causing a deadlock in the
database, because<br>
you're working on rows in the tables that are related, but you access
these<br>
rows from different transactions/threads. If you don't need this highly
<br>
concurrent actions on exactly the same entity, I'd suggest changing the
tests<br>
to work on different entities concurrently. That may solve your problem
right here.<br><br>
<br>
If the deadlock is database related, some (most?) databases ( Oracle,
Sybase )<br>
have facilities to get info about deadlocks. I know only how in Oracle.
The best <br>
bet then is to:<br><br>
* Run the test<br>
* Wait for the deadlock to occur and ( for Oracle )<br>
* execute the following SQL's. You may need to login as SYS or have DBA
role assigned:<br><br>
<br>
<pre>SQL> select * from v$locked_object;
select object_name from dba_objects where object_id = .... ;
</pre><font face="Courier New, Courier"></font>For more info go to
groups.google.com or consult the database documentation.<br><br>
<br>
If you do definitely need highly concurrent access on same entities and
you cannot change<br>
code or there are no apparent ways to fix it, you *will* need to
synchronize the access to <br>
the entities somehow. Ways of doing this are outside the scope of
the topic. Another way<br>
is to divide the data somehow so that the concurrent access simply does
not occur.<br><br>
<br>
Another thing I can think of is when you use "synchronized" in
your code anywhere.<br>
Maybe thread A is trying to get access to a code block where thread B is
currently <br>
executing in. When thread A holds exclusive access to a resource that
thread B needs, <br>
thread B cannot complete the block and both threads will wait ( sometimes
indefinitely,<br>
depending on the type of resource). If you do use
"synchronized" anywhere, verify<br>
that you do not use resources that you have acquired before you executed
the block, but<br>
acquire them within the block if you definitely need the resource access
within the block.<br>
The worst here is a combination of "synchronized" blocks that
are intertwined. The JVM,<br>
other than a database, will not detect these deadlocks and it will simply
hang forever.<br><br>
<br>
Many deadlocks occur due to race-conditions. Therefore if you start
looking for it through<br>
the use of a debugger, you may suddenly not encounter the deadlock at all
because now you<br>
are changing the speed of execution of at least one of the threads. This
is a <br>
good point to remember before you start debugging.<br><br>
Hope that helps,<br><br>
Gerard<br><br>
At 01:36 28/9/2004, you wrote:<br>
<blockquote type=cite class=cite cite="">Hi,<br><br>
In the code snippet of the DAO factory. The objects of DAO's are
created<br>
using SingleTon pattern.<br>
But I have also doveloped the same factory and I asked the question that
do<br>
Is this the right design or it could create the bottelneck situation for
the<br>
application.<br>
My application was getting hanged during stress testing. So, I raised
this<br>
question.<br><br>
Now, can you explain that is there any flaw when our application is going
to<br>
be used by simoltaneously users.<br>
Your input is appreciable.<br><br>
Manish<br>
<br>
</blockquote></blockquote></body>
</html>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
