Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

database.read and database.execute_sql should not return the session to the pool till the stream is closed #3768

Closed
vkedia opened this issue Aug 8, 2017 · 7 comments
Assignees
Labels
api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. release blocking Required feature/issue must be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@vkedia
Copy link

vkedia commented Aug 8, 2017

Cloud Spanner API says that at any point in time there can be at most one active transaction. But the way database.read and database.execute_query have been implemented, they return the session to the pool immediately. Now that session can be reused for doing something else even before the stream returned by previous database.read has completed. This needs to be fixed so that the sessions is returned to the pool only after the iterator has been completely consumed or closed.
This needs to be done before Beta.

@vkedia
Copy link
Author

vkedia commented Aug 8, 2017

cc @lukesneeringer @bjwatson

@bjwatson
Copy link

bjwatson commented Aug 8, 2017

Thanks @vkedia. At a 100K' level, this does sound like a significant usability issue. I'm okay with this being Beta blocking, unless @lukesneeringer or @tseaver have an opinion to the contrary.

@bjwatson bjwatson added api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. release blocking Required feature/issue must be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Aug 8, 2017
@vkedia
Copy link
Author

vkedia commented Aug 8, 2017

@bjwatson This also might be a breaking change depending on how this resolved. For eg the easiest resolution would be to just remove these methods since one can always do the same thing by using a Snapshot.

@bjwatson
Copy link

bjwatson commented Aug 8, 2017

@vkedia That sounds like an easy fix, but definitely surface breaking.

@tseaver
Copy link
Contributor

tseaver commented Aug 9, 2017

I don't think using Database.snapshot solves the problem. Using the current methods:

results = database.execute_sql(SQL)  # returns StreamedResultSet

versus using a snapshot:

with database.snapshot() as snapshot:
    results = snapshot.execute_sql(SQL) # returns StreamedResultSet

The 'StreamedResultSet' we return wraps a low-level GAPIC entity with no existing / obvious link to our session. Given that the user may not iterate to the end (or at all), we would likely have to had some machinery for a "deferred return to pool" and trigger that from StreamedResultSet.__del__.

The other option would be to require that user applications complete all iteration over the StreamedResultSet inside the with database.snapshot() as snapshot: block.

@vkedia
Copy link
Author

vkedia commented Aug 9, 2017

It seems fair to me to expect that user will not access the results object outside of the context block. We can possibly do something to invalidate the iterators when the snapshot is checked back in.

@tseaver
Copy link
Contributor

tseaver commented Aug 10, 2017

Via #3787.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. release blocking Required feature/issue must be fixed prior to next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

3 participants