Thanks Nick. My tests so far running 64 threads a few thousand times all parsing the same NPOIFS or OPCPackage object and I don't get any InvalidFormat exceptions. Doesn't necessarily mean its safe... just a real edge case if it occurred.
They are never written so I think I'll go with Option 2 for now. Caching the OPCPackage makes a huge diference compared to the NPIOFS... I assume because its a zipped. On Wed, Sep 25, 2013 at 12:02 PM, Nick Burch <[email protected]> wrote: > On Wed, 25 Sep 2013, Brian Nesbitt wrote: > >> I want to cache Excel workbook data as close to having a Workbook object >> as possible. I need it just before as there will be multiple threads >> writing data to the cells of the workbook so I want to create a new >> workbook object on each cache access. >> > > That's not generally supported. The thread-safety contract in POI is that > multiple threads can safely write to their own objects without issue, but > not that multiple threads could write to the same object. For example, two > threads are safe to each write to their own HSSFWorkbook instances, but > things can go wrong if two threads are simultaniously writing to the *same* > Workbook object. Ditto for reading (some parts are lazy-parsed) > > > From my tests #2 is faster as I assume some pre-parsing is done by the >>> >> npiofs and opc classes. Are the NPOIFSFileSystem and OPCPackage >> threadsafe? (Can I have multiple threads using the same instance in a >> call >> to WorkbookFactory.create()). >> > > You can pass the same byte array to two different NPOIFSFileSystem objects > in different threads and that'll be fine. If you open a NPOIFSFileSystem > object in one thread, I *think* you should be OK if two threads then read > from the same open NPOIFSFileSystem object. I'm fairly sure things will go > wrong if two threads try to write to the same NPOIFSFileSystem at the same > time, or if one thread tries to interact with a NPOIFSFileSystem object > that another one is only half way through opening. OPCPackage ought to be > broadly similar, but I don't know the details of the code of that so > closely. > > Nick > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
