Subject | Re: [Firebird-Java] Multiple transactions over single socket [Fwd: fb: r6346 - in trunk/rdb_2_1/jaybird/src: main/org/firebirdsql/jca test/org/firebirdsql/jca] |
---|---|
Author | Roman Rokytskyy |
Post date | 2009-11-02T08:27Z |
Hi,
easier if the driver code is not modified at all.
About the patch. From the first look code should work ok in non-managed
environment, but I am not ready to answer about the behavior in a
managed environment - I am not that good in JCA specs to tell if
everything is ok in Xid matching code and connection association when
multiple managed connections are forked.
Now I think there is easier solution:
- database is attached only in one place - in the constructor of the
FBManagedConnection class.
- now, there are only two places where FBManagedConnection is created -
in a FBManagedConnectionFactory.createManagedConnection and in
FBManagedConnectionFactory.tryCompleteInLimboTransaction.
- and finally the FBManagedConnectionFactory is created in:
- AbstractFBConnectionPoolDataSource.getManagedConnectionFactory()
- FBXADataSource.createMcf(...)
- FBSimpleDataSource (constructor)
- FBDriver.connect(...) (two methods)
but in all cases the code depends on FBConnectionProperties contents.
So, I would:
- create a possibility to pass the database handle into
FBManagedConnection constructor.
- create new property that would tell driver to share the attachment
(best way is to add a getter into FirebirdConnectionProperties
interface, that would also tell which places in the code are affected).
- modify the FBManagedConnectionFactory.start() method to check that
property and do an eager attachment.
In this case the code will work the same as of now, only that attachment
will be shared among Connection objects. Any connection that you will
get in a managed and non-managed environment should work correctly as
well, you also would not need to call your custom
forkManagedConnection() method - you simply get the connection from a
DataSource or from DriverManager. Also, if you subclass appropriate data
source and driver classes, you could create a "parallel" version of the
code without modifying the code in the Firebird's trunk. For me this
looks like a better solution.
Roman
> Attached is the code from Eugene Putilin as applied to RDB 2.1 trunk.I have talked with Eugene last week and told me that for me would be
> We integrated the use of this feature into our framework (ncore) and the
> code appears to work.
> The presense of subj capability is critical for our deliverable. I guess
> it can be useful for other people as well.
>
> The code apparently needs a bit of polishing before it can be applied to
> Jaybird HEAD.
> Please let us know what you think.
easier if the driver code is not modified at all.
About the patch. From the first look code should work ok in non-managed
environment, but I am not ready to answer about the behavior in a
managed environment - I am not that good in JCA specs to tell if
everything is ok in Xid matching code and connection association when
multiple managed connections are forked.
Now I think there is easier solution:
- database is attached only in one place - in the constructor of the
FBManagedConnection class.
- now, there are only two places where FBManagedConnection is created -
in a FBManagedConnectionFactory.createManagedConnection and in
FBManagedConnectionFactory.tryCompleteInLimboTransaction.
- and finally the FBManagedConnectionFactory is created in:
- AbstractFBConnectionPoolDataSource.getManagedConnectionFactory()
- FBXADataSource.createMcf(...)
- FBSimpleDataSource (constructor)
- FBDriver.connect(...) (two methods)
but in all cases the code depends on FBConnectionProperties contents.
So, I would:
- create a possibility to pass the database handle into
FBManagedConnection constructor.
- create new property that would tell driver to share the attachment
(best way is to add a getter into FirebirdConnectionProperties
interface, that would also tell which places in the code are affected).
- modify the FBManagedConnectionFactory.start() method to check that
property and do an eager attachment.
In this case the code will work the same as of now, only that attachment
will be shared among Connection objects. Any connection that you will
get in a managed and non-managed environment should work correctly as
well, you also would not need to call your custom
forkManagedConnection() method - you simply get the connection from a
DataSource or from DriverManager. Also, if you subclass appropriate data
source and driver classes, you could create a "parallel" version of the
code without modifying the code in the Firebird's trunk. For me this
looks like a better solution.
Roman