beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie O'Neil" <>
Subject Re: Doubts on Apache Beehive.
Date Sun, 04 Dec 2005 16:54:13 GMT

   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!


James Black wrote:
> 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
> Version: GnuPG v1.4.0 (MingW32)
> iD8DBQFDkQamJ/zyYkX46joRAiZbAKCW4q2xNxy9HldPBpbwVNrcZ+KqngCeLfAD
> jzyKs/R4gri96dzyWe+bV8A=
> =/j6L

View raw message