Re: SCB1381 - Scarab summary page
Johannes Hoechstaedter <[email protected]>
| Newsgroups | gmane.comp.java.scarab.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Ronny, I agree with that, except I don't know why you think, that the instance of module can be different. The report instance is created by: new ReportBridge(ReportManager.getInstance(new NumberKey(id), true)); Völker Ronny schrieb: > We could live with this, but when I think about it... > ... the whole thing is still a workaround. > > I wonder if we could just throw away the whole ReportTableModel instead of cleaning the getValueAt-cache when an issue is changed. > > We could reuse the defaultReportDirty-property of ScarabModule you have introduced in your second patch. > When an issue is changed issue.getModule.setDefaultReportDirty() would be called and the next execution of the report would throw away the old ReportTableModel which means that the cached values of getValueAt of the old instence wouldn't be used anymore and eventually released by the cache. > > I know this is a bit against the advices I gave you about the caching, but because there is no relation between the Issue and the ReportTableModel we need this indirection. > > There is just one problem with this: we have to be sure that issue.getModule and report.getModule are returning the same Instance of ScarabModule for the same module. > > What do you think? > > Ronny > -----Original Message----- > From: Johannes Hoechstaedter [mailto:[email protected]] > Sent: Wednesday, March 05, 2008 12:32 PM > To: [email protected] > Subject: Re: SCB1381 - Scarab summary page > > Hi :) > > yes, it works now. Everything works, except the follwing: > > We did a multi user test right now: > If user A changes an issue in module 1, scarab clears the report values > cached for module 2 from user B, too. > > cheers > > Völker Ronny schrieb: > >> Oops, you are right. >> >> In this code all instances ReportTableModel share the same cached values, which is obviously wrong. >> But our problem remains, that we don't have a ReportTableModel-instance when we clear the cache. >> >> As far as I know, the MethodResultCache does not support directly removing the results of a method for all instances of a class. >> A workaround is the following: >> getMethodResult().get(REPORT_TABLE_MODEL, GET_VALUEAT, this, new Integer(row),new Integer(column)); >> getMethodResult().put(contents, REPORT_TABLE_MODEL,GET_VALUEAT, this, new Integer(row),new Integer(column)); >> getMethodResult().removeAll(REPORT_TABLE_MODEL,GET_VALUEAT); >> You can think of this as ReportTableModel would have a static method getValueAt, which takes an instance of ReportTableModel as first argument. >> >> Btw, the two constants are better located in ScarabReportTable or ReportManager because they don't make sense elsewhere. >> >> Ronny >> >> -----Original Message----- >> From: Johannes Hoechstaedter [mailto:[email protected]] >> Sent: Wednesday, March 05, 2008 11:15 AM >> To: [email protected] >> Subject: Re: SCB1381 - Scarab summary page >> >> Hi, >> >> ok I introudced some finals in ScarabConstants. It works. My question is >> now, is scarab still ready for multi user usage? >> >> The code in ScarabReportTable looks like this now: >> >> ReportManager.getMethodResult().get(ScarabConstants.REPORT_TABLE_MODEL,ScarabConstants.GET_VALUE_AT,new >> Integer(row),new Integer(column)); >> >> And in ActivitySetManager like this: >> >> ReportManager.getMethodResult().removeAll(ScarabConstants.REPORT_TABLE_MODEL,ScarabConstants.GET_VALUE_AT); >> >> cheers >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > >