Why does the HBase Thrift API always return a thri

Question

For every thrift API call ( using HBase Thrift in Erlang )the API returns a thrift connection:

erlang example:

% creating the initial connection

{ok, TFactory}          = thrift_socket_transport:new_transport_factory( "localhost", 9090, []),
{ok, PFactory}          = thrift_binary_protocol:new_protocol_factory(TFactory, []),
{ok, Protocol}          = PFactory(),
{ok, ThiftConnection1}  = thrift_client:new(Protocol, hbase_thrift),    

%calling a row mutation

{ThriftConnection2, Result} = thrift_client:call( ThriftConnection1, mutateRow, ["MYTABLE", Row1Id, MutationList1, dict:new()]),
{ThriftConnection3, Result} = thrift_client:call( ThriftConnection2, mutateRow, ["MYTABLE", Row2Id, MutationList2, dict:new()]),

This raises the related inquiries below:

1. Should I always use the returned connection or just the first one ?
2. Are these connections the same ?
3. Will this pass-along-connection approach cause connection leaks ?
4. Is there a way to close these connections or they have their own lifecycle for every type of API call that uses them ?

Answer 1

I realized this is not a connection but a thrift-transport reference. I compared them to each other and they are identical. In Erlang, printing their content (serializing) the facts about each of those results indicate they are the same

ThriftConnection2 :
{tclient,hbase_thrift,
 {protocol,thrift_binary_protocol,
    {binary_protocol,
        {transport,thrift_buffered_transport,
            {buffered_transport,
                {transport,thrift_socket_transport,
                    {data,#Port<0.25469>,infinity}},
                []}},
        true,true}},
    0}

ThriftConnection3 :
{tclient,hbase_thrift,
{protocol,thrift_binary_protocol,
    {binary_protocol,
        {transport,thrift_buffered_transport,
            {buffered_transport,
                {transport,thrift_socket_transport,
                    {data,#Port<0.25469>,infinity}},
                []}},
        true,true}},
    0}