Hi Tobias,
from the description you provided it seams that the field
ShopSystemOrders is defined with lazy="true" in the mapping of Company.
This is the only way I'm aware at the moment, that causes Castor to use
a RelationCollection for them.
Anyway the exception is thrown as the transaction you have loaded the
Company instance in has already been closed. If you would iterate over
the ShopSystemOrders in this transaction you won't see the exception.
That's all I am able to tell according to the information provided and
my Castor experience as long term user and committer. For more help I
would need a test case to reproduce the problem.
Another option for you would be taking up professional services where I
could sign a NDA to take a look at your application myself.
Regards
Ralf
Tobias Prinz schrieb:
> Hello there,
> I am in the a rather unpleasant situation of having to ask a seemingly
> basic question, but I haven't figured out the right search phrases to
> solve it myself. :-(
>
> So we got this little application an intern (gone a long time ago) which
> uses castor jdo (in version 1.1). Think of it as a webshop embedding
> data from another webshop. So it has a lot of complicated relations,
> which I now have to iterate over from one side to the other to do some
> clean-up (checking for subscribed newsletters about products). I tried
> that by simply going from one end (the customer) to the other (the
> products bought) but it always fails with a RuntimeException stating
> "Transaction is closed".
>
> Please note: LicenseDB is -for our purposes- just a wrapper for
> org.exolab.castor.jdo.Database with txBegin() and txCommit() wrapping
> begin() and commit(), plus counting the amount of transactions.
> Contact, ShopSystemOrder, OrderPosition Product and Newsletter, are, of
> course, Castor-JDO-mapped JavaBeans. I am sure I did not break anything
> while removing data our company would consider "sensitive"... anyway,
> here is the code:
>
> public Collection<Newsletter> getNewslettersForCompany(Company company)
> throws PersistenceException {
> LicenseDB database = new LicenseDB();
> try {
> database.txBegin();
> Collection<Contact> contactsOfThisCompany = company.getContacts();
> Collection<ShopSystemOrder> ordersByThisCompany =
> company.getShopSystemOrders();
> Set<OrderPosition> orderPositions = new HashSet<OrderPosition>();
>
> for(ShopSystemOrder order : ordersByThisCompany){ //here it fails...
> Collection<OrderPosition> positions = order.getOrderPositions();
> orderPositions.addAll(positions);
> }
>
> for(OrderPosition orderPos : orderPositions){//...and I still have a
> long way to go
> Product product =
> database.getProductByShopSystemId(orderPos.getPrdId());
> relatedNewsletters.add( product.getNewsletter());
> }
>
> database.txCommit();
> return relatedNewsletters;
> } finally {
> database.txRollbackIfActive();
> database.close();
> }
> }
>
> I do not really understand why this fails. I have googled the error
> message and as far as I understand, this should only happen if lazy
> loading is enabled, because then, the relation is not resolved instantly
> but as late as possible. So I took a look at the .xml files used for
> mapping these entities (I also searched automatically through all files,
> just to be sure) and did not find a single mention of lazy="true" (or
> any "lazy=" at all).
>
> Now I did some debugging. The first Collection, contactsOfThisCompany,
> is fine. It really is a collection.
> The second, ordersByThisCompany, is only a
> org.castor.persist.proxy.RelationCollection, so it is not resolved.
> Even if I remove the first step, the second is not resolved.
> Anyway, the hint always given is to make copies of all collections
> before continuing. Which I tried, by cloning the result of
> company.getShopSystemOrders() but to no avail, as the same error appears.
>
> Should I have cloned company itself the second I got it - then why is
> its first collection resolved, but not second?
> Can I somehow force a collection (or a class containing one) to be
> resolved before my transaction times out?
> Can I extend the timeout?
> What am I doing wrong?
>
> Thanks in advance,
> Tobias Prinz
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
