Teradata session abort AMP CPU threshold - sql

Question

I have an SSIS package that is refreshing SSAS cube partitions. Each partition is a SQL query running against Teradata. I am using "NET data provider for Teradata" in the SSIS package. The SSAS cube is using "Teradata.Client.Provider". Any particular query executes just fine. However, after 5-10 iterations, I get a SESSION ABORT. After some investigation I found out that all queries are using in the same session:
sel * from DBC.DBQLogTbl where sessionid = 123456
This query returns multiple rows with queries from the loop. Each query by itself does not exceed the CPU AMP threshold, however combined AMP usage exceeds the threshold.
I have configured the connection strings in SSIS and SSAS as following:
SSAS: Connection Timeout=180;Authentication Mechanism=LDAP;Response Buffer Size=64000;User Id=***;Data Source=my.production.server;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;Connection Pooling Timeout=15;Command Timeout=900
SSIS: Data Source=my.production.server;User Id=***;Authentication Mechanism=LDAP;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;
I have disabled parallel execution on the cube. I have disabled the connection pooling as you can see from the connection string. I have set "Maximum number of connections" to 1 on the cube.
Any ideas on how I can force each query to have its own session on Teradata?
Update
After some investigation, I am pretty sure there is a bug hidden somewhere in the cube or database driver. The cube just ignores the
Connection Pooling=false;
parameter and executes each SQL command in the same session. So I've looked into how the driver handles pooling. According to the documentation, the connection string is used as a key when storing a connection resource in the pool. Therefore if you supply a different connection string the driver handles such case as "new connection" and does not use the one already existing in the pool. Now I have a script task after each iteration that "shuffles" the parameters of a given connection string and updates the connection on the cube. This is definitely a hack and I do not recommend this as a solution but desperate times call for desperate measures...
string dcs = #"Connection Timeout=180;Authentication Mechanism=LDAP;Response Buffer Size=64000;User Id=***;Data Source=my.production.server;Persist Security Info=True;Session Character Set=UTF16;Connection Pooling=False;Connection Pooling Timeout=15;Command Timeout=900";
Random r = new Random();
var shuffled = dcs.Split(';').OrderBy(x => r.Next()).ToArray();
var newCs = string.Join(";", shuffled);