Re: [infinispan-dev] [ISPN-78] Alternative interface for writing large objects

Hi Galder, thanks for your input. See my comments below: -------- Original-Nachricht -------- Just to make sure that we are on the same page: the supposed call sequence would appear to be 1. User calls OutputStream writeToKey(K key) 2. writeToKey creates a PutKeyValueCommand, marking it as pertaining to a large object. 3. writeToKey passes that command down the interceptor chain. 4. A LargeObjectChunkingInterceptor or maybe LargeObjectMetadataInterceptor processes that command, recognizing it as pertaining to a large object and thus storing a mapping from large object key to an initially empty large object metadata instance. 5. That interceptor returns a specialized output stream. 6. User writes bytes to that output stream until chunk limit is reached. 7. Output stream calls cache.put(key, byte[]) or alternatively creates PutKeyValueCommand itself, passing it down the interceptor chain. 8. LargeObjectChunking/MetadataInterceptor recognizes that it is dealing with a large object and that there already exists a mapping for that key in the metadata cache. 9. Interceptor generates new chunk key. 10. Interceptor replaces key with new cunk key and calls the next interceptor. 11. Interceptor restores original key (if only consistency reasons). 12. Repeat 6 - 11 until user closes output stream. Makes sense. Thanks. Found some example code in the meantime. It's obviously no rocket science. Implemented a workaround in the meantime. Would be fab if such a service existed. Haven't found it yet. Well, the problem with transactions in this context seems to be that a transaction *always* holds it entire associated state. In our situation this would potentially blow up the heap. Reading might not be a problem since in my original design a reader would not find a mapping for a key as long as the writer has not finished writing. It would assume that the large object it is looking for does not exist. In the updated design suggested above I currently think about marking the metadata as being incomplete. A reader could then either block until the writer is finished, or it could inform the reader about it. I haven't thought deeply about the implications for concurrent writes, though. Is it possible to lock keys outside of a transactional context? If so, this might be a solution for reading and writing. Cheers, Olaf -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de