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.
Summary: | Transaction-related events | ||
---|---|---|---|
Product: | java | Reporter: | _ hkrug <hkrug> |
Component: | Unsupported | Assignee: | issues@java <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | mmatula, sdedic |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
URL: | http://mdr.netbeans.org/servlets/BrowseList?listName=dev&by=thread&from=12551&to=12551&first=1&count=4 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
_ hkrug
2002-06-27 07:12:16 UTC
Thanks for your answers. I just got confused by your initial e-mail, where you requested both new events and a transaction context passed to events. This is obviously more complicated than providing just events. I propose to have events (possibly on the repository) in a similar way that there are events on other objects, receiving synchronous and asynchronous transaction begin and end, only for outermost read/write (not readonly) transactions. Does that seem reasonable to you? (I am quite busy now - I'm at the OMG Technical Meeting - so I have only small breaks during which I can reply to e-mail, but in the evening I should be able to put together a more concrete proposal of the new API). Only outermost read/write transactions is OK. Transaction begin/end events on repositories is OK. Additionally I must get knowledge about which events belong to which transaction. That would be possible if an order of listener invocation is defined (namely for each transaction: first transaction begin event, then all change events belonging to that transaction, then transaction end event). Probably listeners are invoked in a certain order, but that order is currently not documented. So it would be enough to amend the Javadoc of the MDR event API in that point for pre-change and post-change listener invocation. Changes to that order will then count as API changes. Ordering of pre-change listeners is implicit - because they are synchronous. Ordering of change listeners has to be the same as ordering of pre-change listeners (we have also tests that check that) and that is how it is always going to work. But you are right that I have forgotten to state it explicitly in JavaDoc, so I will fix that. (I am planning to have both pre-change and chage events also for transactions - this way the change event can confirm that the transaction that was planned to be commited was really commited, not rolled back) Fine. This way it will work. fixed (see also issue #25186 for more discussion on this topic) |