Limiting a series of commands to a single, locked connection

[Nick Sahler]

Hi!

In the case that I wanted to add this functionality to mongoose:

• Have a connection pool (default functionality, obviously); But,
• Be able to lock a connection, so that it can't be used by any other process using mongoose until it's unlocked and 
• Assure that the process that grabbed the monitor for that period of time *only* sends commands using that connection, and can unlock it when it's done

Would it be wise to do this at the high level, by creating a bunch of instances of Mongoose with a poolsize of 1, and registering my Schemas on all of them on initialization, then managing the lock/monitor process by passing something an instance, or should I override something in mongoose itself that manages the connections array?

Any advice is greatly appreciated. Thanks!

[Sergey Lyubka]

On Thu, Sep 19, 2013 at 4:47 PM, Nick Sahler <ni...@sahler.co> wrote:

Hi!

In the case that I wanted to add this functionality to mongoose:

• Have a connection pool (default functionality, obviously); But,
• Be able to lock a connection, so that it can't be used by any other process using mongoose until it's unlocked and 

Could you elaborate on what connection locking is?

Maybe a use case scenario?

 

• Assure that the process that grabbed the monitor for that period of time *only* sends commands using that connection, and can unlock it when it's done

Would it be wise to do this at the high level, by creating a bunch of instances of Mongoose with a poolsize of 1, and registering my Schemas on all of them on initialization, then managing the lock/monitor process by passing something an instance, or should I override something in mongoose itself that manages the connections array?

Any advice is greatly appreciated. Thanks!

--
You received this message because you are subscribed to the Google Groups "mongoose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-user...@googlegroups.com.
To post to this group, send email to mongoos...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongoose-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Nick Sahler]

Scenario:

Process A is called, its job is to create 3 Items, and increment a number on another object that it finds by querying.
It gets called, and requests a connection to the DB. Once that connection is given, it cannot be used by another Process, and Process A must route all of its querying, saving, updating (any commands to mongodb) through that connection. After Process A is done, it must release that connection, so another process can be given it.

When Process A requested that connection, a theoretical connection manager (the thing I am wondering about what level it would be wise to implement) selects one randomly from a pool. If it's locked, it selects another one, until it gets a free one, and then locks it and returns it.

Say Process A is called again, so you have it running at the same time as the first, this new instance of Process A will be running on a completely separate connection as the first one.

I hope I explained that well enough :O

[Sergey Lyubka]

I see. DB connections used by web server must be sticky to certain HTTP session.

What you need is make a session, and pass it - through request parameter or HTTP header (e.g. cookie).

Server side would extract a session by provided identifier. Store your connection in a session descriptor.

[Nick Sahler]

No. This has nothing to do with sessions - it is entirely serverside.
I don't believe that's a viable solution - and also creates some security issues. My question is about the mongoose pipeline.

[Sergey Lyubka]

Could you elaborate on why do you think it's not sessions related please?

As far as I understand, your goal is to pin client to a DB connection.

The ONLY way to do it is with a some sort of client identifier.

Which is essentially a session ID.