This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I suggest not using boolean for the parameter for MDRepository.endTrans(boolean rollback). There is not an obvious mapping true->rollback false->commit. It could very well be true->commit and false->rollback, if you are coding "blind". I think that something like MDRepository.endTrans(MDRepository.COMMIT) and MDRepository.endTrans(MDRepository.ROLLBACK) are much more clear. Or, even two seperate methods "rollback" and "commit". Or, perhaps you could just use the Java Transaction API instead?
Hi Brian, you are right. What about the boolean parameter in beginTrans, is it intuitive? I am also trying to see how the jta fits with MDR. There are some problems I can see: 1) how to deal with nested transaction in context of JTA 2) which JTA interfaces are relevant for MDR 3) fact that the JTA is not part of standard distribution of J2SE, thus we will have to go through a complicated legal process before we will be able to use it in the MDR I do not know much about JTA so I will need to read through it more. I am not sure if it is suitable for the kind of transactions that MDR supports. If you can provide me with your resolution to the first two issues, it would be perfect.
No, the boolean parameter in beginTrans() is just about as confusing, so I suggest a similar change. But endTrans() is the one I always have to look at the documentation each time.
I did a little bit of reading about JTA. First, I will answer your questions: 1. The JTA spec clearly and explicitly states that nested transaction support is NOT required. 2. The JavaDoc is at: http://java.sun.com/products/jta/javadocs-1.0.1/index.html Basically, you would need to provide an implementation of javax.transaction.UserTransaction. Additionally, you might want to provide an implementation of TransactionManager. At the very least, you need to have some API for getting a UserTransaction instance. All of the other interfaces are designed for application-server scenerios. And, all "XA" interfaces are explicitly for distributed transactions. Here is a good tutorial resource: http://www.onjava.com/pub/a/onjava/2001/06/06/j2ee_trans.html?page=1 Notes: The primary motiviation of JTA is support for distributed and coordinated transactions. That is why it is in J2EE and not in J2SE. On the other hand, JTA makes provisions for "local transactions" that aren't managed by a global transaction coordinator. And, all methods in javax.transaction.UserTransaction seem to be relevent to applications like MDR. So, MDR could support "local transactions" and potentially an "Enterprise MDR" would end up using the same API to support coordinated transactions. One significant aspect of JTA to be aware of is the transaction-thread mapping. Each thread is associated with exactly zero or one global transaction. That means that a single thread cannot take part in multiple global transactions. But, multiple threads can all take part in a single global transaction. I'm not exactly certain yet if local transactions require thread-transaction mapping. Also, I don't know how MDR currently does (or plans to do) the thread-transaction mapping, but it seems that it must be using threads to keep track of transactions anyway. I think that JTA is a good API for something like MDR. But, definitely you would need to provide good documentation explaining what espects of JTA are relevent to MDR and which are not. In particular, one shouldn't have to go try to read the JTA specification to use MDR, since the JTA spec. spends most of its time explaining transaction coordination. On the other hand, if you feel that JTA is out-of-scope or otherwise inappropriate, I suggest using JTA as at least a model for a transaction API. In particular, you could reuse the method names, constants, and semantics from the UserTransaction and Status interfaces.
I am closing all reports in category Java/Unsupported as wontfix. These should be dead issues --- if the reported cases are against some live part of the NetBeans IDE please reopen and we can discuss to which category they belong.