Important conceptual question about Application Module, Maximum Pool Size

Question

Hello everyone,
We have a critical question about the Application Module default settings (taking the DB connections from a DataSource)
I know that on the Web it is generally suggested that each request must end with either a commit or rollback when executing PL/SQL blocks "directly" on the DB without the framework BC/ViewObject/Entity service intervention.
Now, for some reasons, we started to develop our applications with thinking that each Web Session would reference exactly one DB session (opened by any instance taken from the AM pool) for the whole duration of the session, so that the changes made by each Web session to its DB session would never interfere with the changes made by "other" Web Sessions to "other" DB sessions .
In other words, because of that convincement we often implemented sort of "transactions" that open and close (with either commit or rollback) each DB session not in/after a single HTTP request, but during many HTTP Requests.
As a concrete example think of this scenario:
1. the user presses the "Insert" button. An HTTP request is fired. The action listener is executed and ends up with inserting rows in a table via a PL SQL block (not via the ViewObjects API).
2. no commit or rollback after the above PL/SQL block is done yet.
3. finally the user presses a "Commit" or "Rollback" button, firing the call to the appropriate AM methos.
Those three requests consist of what I called "transaction".
From the documentation it's clear that there is no guarantee that the couple AM istance + DB session is the same during all the requests.
This means that, during step 2, it's possible that another user might reference the same "pending" AM/DbSession for his needs and "steal" somehow the work done via PL/SQL after step 1. (This happens because sessions taken by the pool are always rolled back by default.)
Now my question is:
Suppose we set the "Maximum Pool Size" parameter to very a great number (always inferior to the maximum number of concurrent users):
Is there any guarantee that all the requests will be isolated in that case?
I hope the problem is clear.
Let me know if you want more details.

Answer 1

Thanks for the answers.
If I am right, from all your answers about resource avaiability, this means that even supposing the framework is able to always give us the same AM instance back from the AM pool (by following the session-affinity criterias), there is, however, no "connection affinity" with the connections from the DataSource. This means that the "same AM instance" might take the "a new DB connection", if necessary, from the connection pool of the DataSource. If that happens, that could give us the same problems as taking "a new AM instance" (that is, not following session-affinity) from the beginning, since each time an a new connection is taken (either via a new AM instance or via the same AM instance plus a new DB connection), the corresponding DB session is rolle back by default, clearing all the pending transactions we might have performed before with direct PL/SQL calls bypassing the AM services during the life cycle of our application, so that the new HTTP request will have a clean DB session to start to work with.