Home » Modeling » EMF » [CDO] Exception Handling on Commit
|
| Re: [CDO] Exception Handling on Commit [message #900428 is a reply to message #900378] |
Tue, 07 August 2012 05:26   |
|
Am 06.08.2012 19:52, schrieb Christoph Keimel:
> Hello
>
> I am setting up a rcp application based on CDO/Hibernate. I am currently working on fallback exception handling
> strategies on a commit. I have noticed that the CommitException does not include a cause (getCause() returns null).
That seems to be an "exception", not the general rule. How exactly does this exception look like, where is it being thrown?
> I assume that this is quite reasonable in many cases, since one does not have to worry about having obscure exceptions
> on the classpath that arrise from somewhere within the jdbc implementation.
I guess you're referring to the fact that some exception classes themselves are not on the classpatch of a client
application, only on the classpatch of the server deployment. Because the server can not know what classes are available
on the client (except those in net4j, net4j.util and cdo.common) all stacktraces are also transferred in String form to
the client. See RemoteExceptionRequest and RemoteExceptionIndication for details.
> On the other hand, I would like to create some default error messages based on exceptions that arrise from constraint
> violations (org.hibernate.exception.ConstraintViolationException). I could parse the message from the CommitException,
> which holds the exception stack trace, but I was wondering if there es a more elegant solution to this.
Didn't you say that, in your case, there is no cause/stacktrace available?
> I have tried to set up an ExceptionHandler in the CDONet4jSessionConfiguration before the CDOSession is opened, but
> the handleException method doesn't get called. (I verified, that it is correctly set in the CDOSession with
> getExceptionHandler().)
>
> So question #1 is: Should the ExceptionHandler be notified of commit exceptions?
No. CommitExceptions are special in that they are created on the client side from the rollbackMessage that is received
from the server in case of "failed" commits. In other words, non-transport commit problems are handled on
application-(protocol-)level.
> If not, when will this ExceptionHandler be used?
This handler is mostly used to intercept transport-level exceptions. The RecoveringCDOSessionImpl is an example:
private class RecoveringExceptionHandler implements ExceptionHandler
{
public void handleException(CDOSession session, int attempt, Exception exception) throws Exception
{
if (exception instanceof TransportException)
{
recover();
}
}
}
>
> Question #2: Is it possible to hook into the server for exception handling?
Not yet, I think.
> Maybe use custom exceptions with appropriate error messages for common constraint violations.
What problems would you define as "common"? Perhaps you can start with some examples?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Exception Handling on Commit [message #900508 is a reply to message #900378] |
Tue, 07 August 2012 10:41 |
 Christoph Keimel
Messages: 482
Registered: December 2010
Location: Germany |
Senior Member |
|
|
I am most happy to abide ... thanks for taking the time to help.
Consider this model element (xcore):
class MyElement {
unique String name
String description
}
Which gets these persistence annotations (for Hibernate):
<eclass name="MyElement">
<eattribute name="name">
<column nullable="false" unique="true"/>
</eattribute>
</eclass>
The resulting database definition now has a table "myelement" with a column "name". The column "name" has a "not null" constraint as well as a "unique" constraint.
On the client I execute the following test (where IEmTracRepoService is a simple client interface to handle the setup of the CDOSession):
public void testNotNullConstraintViolation(IEmTracRepoService repo) {
// TODO Exception Handling bei Constraint-Violations
CDOTransaction transaction = repo.openTransaction();
try {
CDOResource resource = transaction.getOrCreateResource(repo.getResourceName());
MyElement element = EmTracFactory.eINSTANCE.createMyElement();
resource.getContents().add(element);
element.setDescription("Test Element without a Name");
transaction.commit();
} catch (CommitException e) {
logger.error("CommitException", e);
} finally {
transaction.close();
}
}
This throws a CommitException as expected, because the name has not been set. This is the stack trace which is logged (shortened):
12:16:41.090 ERROR d.e.e.a.h.TestNotNullConstraintViolation - CommitException
org.eclipse.emf.cdo.util.CommitException: Rollback in HibernateStore: org.hibernate.exception.ConstraintViolationException: Column 'name' cannot be null
at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:75)
...
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column 'name' cannot be null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
...
I would like to be able to get the originating message of the exeption, which is "Column 'name' cannot be null" in this specific case. "e.getMessage()" returns the full stack trace as a String. Since "e.getCause()" returns null it is not possible to walk the exception hierarchie.
If the client handles everything well, this situation will not happen, because everything has been checked before the commit is sent. But sometimes constraints get added later, or the check is simply forgotten and then the rdb constraints kick in. This is why I am talking about a "fall back exception handling". It would be nice to still be able to produce good error messages for the user.
It would be nice, if I could get the MySQLIntegrityConstraintViolationException as an object, because this also holds additional information (vender code, etc.)
Greetings
Christoph
|
|
|
| Re: [CDO] Exception Handling on Commit [message #900572 is a reply to message #900508] |
Tue, 07 August 2012 15:07 |
|
Am 07.08.2012 12:41, schrieb Christoph Keimel:
> I am most happy to abide ... thanks for taking the time to help.
>
> Consider this model element (xcore):
> class MyElement {
> unique String name
What does "unique" mean here? I thought it's just meaningful for many-valued features.
> String description
> }
> Which gets these persistence annotations (for Hibernate):
> <eclass name="MyElement">
> <eattribute name="name">
> <column nullable="false" unique="true"/>
> </eattribute>
> </eclass>
> The resulting database definition now has a table "myelement" with a column "name". The column "name" has a "not null"
> constraint as well as a "unique" constraint.
>
> On the client I execute the following test (where IEmTracRepoService is a simple client interface to handle the setup
> of the CDOSession):
> public void testNotNullConstraintViolation(IEmTracRepoService repo) {
> // TODO Exception Handling bei Constraint-Violations
> CDOTransaction transaction = repo.openTransaction();
> try {
> CDOResource resource = transaction.getOrCreateResource(repo.getResourceName());
> MyElement element = EmTracFactory.eINSTANCE.createMyElement();
> resource.getContents().add(element);
> element.setDescription("Test Element without a Name");
> transaction.commit();
> } catch (CommitException e) {
> logger.error("CommitException", e);
> } finally {
> transaction.close();
> }
> }
> This throws a CommitException as expected, because the name has not been set. This is the stack trace which is logged
> (shortened):
> 12:16:41.090 ERROR d.e.e.a.h.TestNotNullConstraintViolation - CommitException
> org.eclipse.emf.cdo.util.CommitException: Rollback in HibernateStore:
> org.hibernate.exception.ConstraintViolationException: Column 'name' cannot be null
> at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:75)
> ..
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column 'name' cannot be null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> ..
>
> I would like to be able to get the originating message of the exeption, which is "Column 'name' cannot be null" in
> this specific case. "e.getMessage()" returns the full stack trace as a String. Since "e.getCause()" returns null it is
> not possible to walk the exception hierarchie.
>
> If the client handles everything well, this situation will not happen, because everything has been checked before the
> commit is sent. But sometimes constraints get added later, or the check is simply forgotten and then the rdb
> constraints kick in. This is why I am talking about a "fall back exception handling". It would be nice to still be
> able to produce good error messages for the user.
>
> It would be nice, if I could get the MySQLIntegrityConstraintViolationException as an object, because this also holds
> additional information (vender code, etc.)
Ah, you are willing to put the exception class(es) on the client's classpath! Then you should have no problems because
the org.eclipse.net4j bundle declares Eclipse-"BuddyPolicy: registered" exactly for this use case. Just put
"Eclipse-RegisterBuddy: org.eclipse.net4j" into the manifest of the bundle that contributes your exception classe(s).
Some more infos about buddy classloading:
http://rajakannappan.blogspot.de/2010/03/eclipse-classloading-and-buddy-policy.html
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Exception Handling on Commit [message #900661 is a reply to message #900608] |
Wed, 08 August 2012 05:23 |
|
Am 07.08.2012 20:38, schrieb Christoph Keimel:
>
>> Ah, you are willing to put the exception class(es) on the client's classpath! Then you should have no problems
>> because the org.eclipse.net4j bundle declares Eclipse-"BuddyPolicy: registered" exactly for this use case. Just put
>> "Eclipse-RegisterBuddy: org.eclipse.net4j" into the manifest of the bundle that
>> contributes your exception classe(s).
>
> Sounds perfect :). I added "Eclipse-RegisterBuddy: org.eclipse.net4j" to both the org.hibernate plug-in and the
> com.mysql.jdbc plug-in (my own copies, so I can edit the MANIFEST.MF). This does not have any effect on the
> CommitException. The cause is still null. (I verified that the correct plug-ins are available.)
That's what I originally meant when I said "CommitExceptions are special in that they are created on the client side
from the rollbackMessage that is received from the server in case of "failed" commits. In other words, non-transport
commit problems are handled on application-(protocol-)level."
> I was debugging into the code and I couldn't find the position where the original exception would be instantiated.
Please set breakpoints on all constructors of the exception class in question and start stepping (out) from there to see
where in CDO they're caught/handled. You don't require the source code of Hibernate for that.
> The CommitException gets thrown in CDOSingleTransactionStrategyImpl because the rollbackMessage in
> CommitTransactionResult is not null.
See above ;-)
> Could you please give me a pointer on where to start looking?
Set the breakpoints. You'll end up in
org.eclipse.emf.cdo.internal.server.TransactionCommitContext.handleException(Throwable).
> Or am I looking in the wrong place all together? Is there more information in the transaction or in the session? I
> tried transaction.getSession().getCommitInfoManager().getCommitInfo(transaction.getLastCommitTime())
transaction.getLastCommitTime() is probably already zero.
> but this returns null too ... probably because the commit never completed.
Yes.
> Or is this an issue with the Hibernate-Store?
No, I think this works as designed.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Exception Handling on Commit [message #900834 is a reply to message #900683] |
Wed, 08 August 2012 16:35 |
|
Am 08.08.2012 09:27, schrieb Christoph Keimel:
> Hi Eike,
>
> What I don't understand is how to get the originating exception on the client-side.
You can't at the moment.
> Or to put it in code:
> public void testNotNullConstraintViolation(IEmTracRepoService repo) {
> CDOTransaction transaction = repo.openTransaction();
> try {
> ... do something to the model ...
> transaction.commit();
> } catch (CommitException commitException) {
> // This will be an instance of org.hibernate.exception.ConstraintViolationException
> // in case of a constraint violation
> Exception cause = getOriginatingException(commitException, transaction);
> } finally {
> transaction.close();
> }
> }
>
> private Exception getOriginatingException(CommitException commitException, CDOTransaction transaction) {
> ???
> }
> How to implement getOriginatingException ... ?
The commit network protocol and some API would have to be changed accordingly. I pointed you to the code in the server
that the exception is passed to to handle it. from there you could come up with a patch to transport it to the client
and make it available much like RemoteExceptionRequest/Indication.
>
> From your previous answers I was expecting some kind of Class.forName(...) in org.eclipse.net4j when net4j tries to
> recreate the exception from the signal result (or something like that). Otherwise why should net4j require buddy
> registering of the bundle that contributes the exception classes?
That is for signals but the commit signal family.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
| Re: [CDO] Exception Handling on Commit [message #902457 is a reply to message #902413] |
Fri, 17 August 2012 17:07 |
|
Hi Christoph,
I think you're required to submit a bugzilla and attach your patch there. I'll look at it then ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 17.08.2012 16:04, schrieb Christoph Keimel:
> Hi Eike,
>
> I did some work on the subject. My approach is to add the exception causing the rollback to the CommitTransactionResult. This way, there is no big change in the API. The client will ignore the exception, if it runs into a ClassNotFoundException. Otherwise it will be passed to the CommitException as cause.
>
> Please have a look at the patch attached and tell me what you think. (This is a git patch on the master branch commit 5f615d8ac9ddc4b22e6be492be5f43b6d3621f09 from Wed Aug 15 16:22:50 2012 +0200).
>
> This seems to work fine, but I am running into a problem concerning the class loading. If I add the bundles contributing the exception as a dependency to org.eclipse.net4j.util, everything works as planned. This is of course not a good idea. I also tried to register the plug-ins with "Eclipse-RegisterBuddy: org.eclipse.net4j.util", but this doesn't change the effect.
>
> I don't understand the part of the code resolving the class ... do you (or anybody else) have any idea what I could be missing?
>
> Thanks for the support!
> Christoph
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 22:34:43 GMT 2024
Powered by FUDForum. Page generated in 0.03317 seconds |
] 
Search
Help
Register
Login
Home
. I added "Eclipse-RegisterBuddy: org.eclipse.net4j" to both the org.hibernate plug-in and the com.mysql.jdbc plug-in (my own copies, so I can edit the MANIFEST.MF). This does not have any effect on the CommitException. The cause is still null. (I verified that the correct plug-ins are available.)