On Fri, 03 Sep 2004 04:54:58 -0600, Bruce Snyder wrote:
>Mattias Bogeblad wrote:
>
>> I used to put some logic in the stored method which did castor
>> cache-refreshes remote and some other logic. It seemed however that the
>> locks were not released on the entities when "stored" was called so the
>> application just hung. Is that the right conclusion?
>
>There is no stored() method. If there were such a method it would imply
>that an object has been persisted (past tense). However, there is a
>storing() method, implying that an object is currently being persisted
>(present tense). If you're trying to flush the cache while a tx is in
>process, yes very bad things could occur. Werner could comment more on
>cache flushing during a tx. He is more familiar with the caching scheme
>lately.
>
>> It is very important for me to be able to decide if the entity is really
>> going to be commited or not - is that absolutely decidable in
>> created/updated? Is the transaction absolutely over when those calls are
>> made so I don't get a lock problem again?
>
>The created() callback method is called in:
>
> TransactionContext.update()
> TransactionContext.create()
> TransactionContext.prepare()
>
>and the updated() callback method is called in:
>
> TransactionContext.markUpdate()
>
>So it seems like this may be what you're looking for, but I'm not fully
>aware of your situation. Try them out and let us know.
>
>Well the tx is only complete after commit() is called successfuly and
>TransactionContext._status = Status.STATUS_COMMITTED (this is in the
>TransactionContext.commit() method on line 1674). Please note that there
>is also the org.exolab.castor.persist.TxSynchronizable interface. This
>is a callback interface with two methods: committed() and rolledback().
>an impl of this class can be registered using
>TransactionContext.addTxSynchronizable() and can be deregistered using
>the TransactionContext.removeTxSynchronizable() methods. This might be
>more of what you're need. But now that I'm looking at it, I don't see a
>manner in which to get a handle on the current tx. the only thing I see
>a method:
>
> protected TransactionContext DatabaseImpl.getTransaction()
>
>I wonder if this should be made public and exposed via the Database
>interface?
Imho, no.
>But I'm not sure if this method should be exposed to the
>user.
Again, it should not.
> I'm not sure if the tx should be exposed to the casual user. I
>believe that the intention of the TxSynchronizable interface was for
>internal use.
I think you are right in that it was meant to be for internal use only
(RelationCollection uses this interface to be informed about commits/rollbacks to the
current transaction). But what prevents us from making this available publicly ? I
agree that we should not make getTransaction() public, but we could
add calls to register/deregister such listeners to Database/DatabaseImpl, couldn't we
?
>I'm just wondering if it's a solution for Matthias.
>
>Committers et al., could you please render some comments on this?
Above .. ;-).
>
>
>Bruce
>--
>perl -e 'print
>unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
>
>The Castor Project
>http://www.castor.org/
>
>Apache Geronimo
>http://incubator.apache.org/projects/geronimo.html
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
