[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933572#comment-14933572
]
Tilmann Zäschke commented on JDO-747:
-------------------------------------
??My understanding of the persistent-deleted state is that the object was
deleted in the current transaction. So I'd propose that the state of p11 after
refresh would be hollow/persistent-nontransactional. This is the state of an
object that used to be persistent but whose state is not currently known.??
But how can I find out what the cause of the failure was?
* The state is {{HOLLOW_NON_TRANSACTIONAL}}
* The nested Exceptions of the {{JDOOptimisticVerificationException}} are
{{JDOOptimisticVerificationException}}. As I understand there is no way of
telling _why_ it failed.
* Any other call (including {{isDeleted()}}) would just throw
{{ObjectNotFoundException}}, as I understand.
It seems the only way to find out is by calling something and catching
potential {{ObjectNotFoundExceptions}}. I'm not sure this is very nice.
I see several options, but only the last two are halfway nice, I think:
* Changing the state of the Object to {{PERSISTENT_DELETED}}, as proposed
before. But that may conflict with other assumptions as you stated.
* Created a new state, {{PERSISTENT_DELETED_REMOTELY}}
* A dedicated function {{isDeletedInDatastore()}} or
{{objectExistsInDataStore()}}
* {{JDOOptimisticVerificationException}} could have a method that returns the
conflict type, for example {{getConflictType() == OBJECT_NOT_FOUND}}
* The {{JDOOptimisticVerificationException}} thrown by {{commit()}} could allow
a nested {{ObjectNotFoundExceptions}} for deleted objects. In other words, the
type of failure would be communicated through the Exception class.
I haven't thought about this before, so I don't even know how helpful it would
be for recovery to know the cause of the failure. Are we specifying too much
detail here?
> Behavior of delete() with multiple concurrent Transactions
> ----------------------------------------------------------
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
> Affects Versions: JDO 3.1
> Reporter: Tilmann Zäschke
> Priority: Minor
> Labels: concurrency, delete, documentation, refresh(),
> specification
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
> wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
> get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
> {{refresh()}} should not change the object's state. But should it
> still fail with {{ObjectNotFound}}? If refresh should fail, how can I
> ever recover from such a situation, because I can't undelete the
> object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
