Hi Tobias, given the complexity of your environment, are you in a position to provide us with a test case that we can use to replay your problem ?
If your data/application is sensitive and you cannot/do not want to attach your code to e.g. a Jira issue, please do consider to take up professional service through e.g. http://indoqa.com where we'll be able to assist you according to your professional needs. Kind Regards Werner Tobias Prinz wrote: > 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
