Ricardo--
Today, you're right -- sharing a single DB connnection between two
database controls isn't something that's possible. Another option would
be to manage the transactions yourself using a UserTransaction that
wraps all of the database control invocations.
One way that this could be done is to write a control that
"assembles" the customer and inventory controls and then handle
transactions inside of that control's methods. In the future, one can
certainly see using something like @Transaction(required=true) on the
wrapping control.
The Connection sharing could be done by having the JdbcControl
support a ConnectionFactory abstraction that knows how to get /
manufacture a Connection object. Assuming this was built correctly, it
could even be wired up through a Spring config file.
Hopefully, something like this could be added in the next major
release of Beehive (1.1?).
Thanks for the feedback!
Eddie
James Black wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ricardo Constantino wrote:
If I have a database controller with all the db queries used to maintain a
customer records and another database controller to maintain the inventory
of goods. If I've an action of selling goods to a customer where I have to
update the customer debt and the goods inventory, i've to use the 2 database
controller with 2 database connections, because if I make the customer
update and close connection and after that update the goods inventory and I
can't have one transaction.
I mention it below, but if you use a temporary table to hold
uncommitted transactions, then you can open and close the connections,
so it will scale better, as you can handle hundreds or thousands of
simultaneous transactions. You can decide when to delete the
uncommitted transactions, and you have safety, so that if the database
has to restart then the transactions aren't lost.
I already saw that your solution for this problem is putting the database
code in the database, but this type of solutions gives less flexibility of
changing the environment.
You can have a database layer, so you have:
database <-> database layer <-> multiple controllers
The database layer is java code, but you can use hibernation, or any
number of other frameworks. This can be very flexible, as you can have
different database layers for different databases, as they can be
swapped in and out, as long as they extend the same abstract classes or
interfaces.
The database layer is in charge of connections. So, you can have
connection pooling, if you desire, or a single connection per transaction.
You can also just have a temporary table where you store uncommitted
transactions, for example. This is abstracted from the controllers.
The controllers just ask the main database connection class for the
connection. It can either give a new one, if needed, or reuse one that
is part of the same transaction.
The controllers would pass that connection to the other db layer
classes, so you can have separate classes for books, computers and
vegetables.
- --
Corruptisima republica plurimae leges. [The more corrupt a republic, the
more laws.]
Tacitus from Annals III, 116AD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFDkQamJ/zyYkX46joRAiZbAKCW4q2xNxy9HldPBpbwVNrcZ+KqngCeLfAD
jzyKs/R4gri96dzyWe+bV8A=
=/j6L
-----END PGP SIGNATURE-----
