On 3/13/2010 1:43 AM, Nikunj Mehta wrote:
This seems like an artificial constraint to me. Is there any reason why we couldn't open up more than one database connection at a time (or at least allow the possibility for a UA to do so).As specced, it is possible to have multiple concurrent requests at various API entry points, except for the IndexedDatabaseRequest interface. In this particular case, you can only have one request to open a database in a Window object. Given that this is setup kind of work, it does not appear that this limitation amounts to much. If multiple connections to a single DB are required, or if different DBs have to be opened, that would have to be done sequentially, i.e., start a new request only after the previous one completed.
Being forced to have more than one database open to do concurrent work seems like an artificial constraint too. It isn't just an initial setup task; there is a fair amount of complexity that the consumer would have to manage to know which connection to use. It should be fairly trivial for the UA to manage the concurrency (even if the UA just serializes requests) and lets the consumer not have to concern itself with this.Once you have an IDBDatabaseRequest object, it is possible to make one request at a time to open a cursor or create a transaction. It is possible to do this concurrently with opening another database. If multiple concurrent requests are to be made to create and/or open object stores or indexes, different connections in the form of IDBDatabaseRequest objects will be needed. Again, this appears largely an initial set up kind of thing. Besides, given that it is possible to check whether a request is in progress, developers can avoid getting into trouble.
One can create as many IDBIndexRequest and IDBObjectStoreRequest object as required. Once these objects are created multiple operations can be performed in parallel.
Only by opening more database connections though, right? Cheers, Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
