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

Support connection pool for postgresql service #3175

Closed
Zheaoli opened this issue Sep 25, 2023 · 6 comments
Closed

Support connection pool for postgresql service #3175

Zheaoli opened this issue Sep 25, 2023 · 6 comments

Comments

@Zheaoli
Copy link
Member

Zheaoli commented Sep 25, 2023

by using BB8 https://github.com/djc/bb8

@Xuanwo
Copy link
Member

Xuanwo commented Sep 25, 2023

Maybe we can store the prepared statement in the managed connection instead?

@Zheaoli
Copy link
Member Author

Zheaoli commented Sep 25, 2023

Maybe we can store the prepared statement in the managed connection instead?

I think it would be better if we choose to use the connection pool.

In most circumstances, the connection pool will create a new connection if the old connection is invalid and this would be cause some issue because the prepared statement is binding with connection.

@Xuanwo
Copy link
Member

Xuanwo commented Sep 25, 2023

the connection pool will create a new connection if the old connection is invalid and this would be cause some issue because the prepared statement is binding with connection.

We can prepare again with the newly created connection.

@Zheaoli
Copy link
Member Author

Zheaoli commented Sep 25, 2023

the connection pool will create a new connection if the old connection is invalid and this would be cause some issue because the prepared statement is binding with connection.

We can prepare again with the newly created connection.

Not a good idea, I think. Here's the detail

let connection = pool.get().await.unwrap();
connection.query_one(&cachedStatement)

We can't guarantee the connection that is got from the pool is the same connection that is binding with the cached statement. If we choose to cache the connection at the same time, I think the connection pool would be useless

@Xuanwo
Copy link
Member

Xuanwo commented Sep 25, 2023

We can't guarantee the connection that is got from the pool is the same connection that is binding with the cached statement. If we choose to cache the connection at the same time, I think the connection pool would be useless

We could implement in this way:

struct ManagedConnection {
   conn: Connection,
   client: Client,

   put_statement: OnceCell<X>, 
}

let mgd_conn = pool.get().await.unwrap();
let x = mgd_connconn.query_one(&mgd_conn.put_statement);

The statement is always alive with the connection.

@Zheaoli
Copy link
Member Author

Zheaoli commented Sep 25, 2023

You mean we storage the connection and the statement in a same struct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants