You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Chiappone <ch...@gmail.com> on 2006/11/16 17:56:35 UTC
Re: Tapernate Access multiple database
I has asked James about this a while back. Unfortunately i don't
believe there is any support in Tapernate for this.
On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> Hi,
>
> Anybody use Tapernate to access multiple databases? How can I switch to
> another database in runtime? Thank you very much.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
~chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Access multiple database
Posted by Chris Chiappone <ch...@gmail.com>.
I have not yet since the requirement has actually not been needed. It
was something I thought I may need to have in the future. I'm hoping
by then there will be a solution :0
~chris
On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> Thank you. Did you come up with any solution without Tapernate?
>
>
> -----Original Message-----
> From: Chris Chiappone [mailto:chiappone@gmail.com]
> Sent: Thursday, November 16, 2006 10:57 AM
> To: Tapestry users
> Subject: Re: Tapernate Access multiple database
>
> I has asked James about this a while back. Unfortunately i don't
> believe there is any support in Tapernate for this.
>
> On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> > Hi,
> >
> > Anybody use Tapernate to access multiple databases? How can I switch to
> > another database in runtime? Thank you very much.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> ~chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
~chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Tapernate Access multiple database
Posted by Jesse Kuhnert <jk...@gmail.com>.
I don't want to get into a whole "thing" about it because it doesn't
matter to me overly much in the long run but did want to make at least
a couple points. ;) (inlined of course)
On 11/21/06, Sam Gendler <sg...@ideasculptor.com> wrote:
<snipped>
>
> Actually, Spring does so many things that hivemind doesn't (at least
> as far as I am aware), that you can't even compare them. As for
> getting transactionality without writing code, I'd say there's no
> comparison between the single line of 'code' I have to add to an XML
> file in order to wrap a method in transaction semantics (including
> handling of rollbacks, using existing transaction or starting a new
> one) and having to manually add code to do the same thing on every
> service method, especially since I can use wildcards in the XML file
> to handle multiple methods in the same manner. The fact that I can
> swap in and out JTA transactions, hibernate transactions, and JDBC
> transactions, again with only a single modification to an XML file, is
> a godsend as a project grows over the course of its use. When we went
> from one database to 2, and then 3, we didn't have to do anything but
> modify a config file to use J2EE transactions instead of the built in
> hibernate ones. There is just no comparison between the complexity of
> the application context file and the code it replaces.
>
I can think of a few ways to compare them offhand:
-) Spring bean id's / name / and bean aliases are all very
uncomfortable naming schemes for me. It would be like having to
manually create all of the unique client id's that Tapestry gives you
in an html page by hand. Bleh . Hivemind has true namespace support,
which means I can easily/cleanly segment off my various services using
"foo.bar.name" type familiar conventions without having to worry about
ID conflicts blowing up on me.
-) Hivemind has thread support / Factory Support / Pipeline support /
Chain of Command and probably others. All incredibly useful
programming concepts captured and available "for free".
-) Hivemind lazily initializes everything "by default".
-) Hivemind allows me to create shared configuration points that
anyone can contribute to...Whether directly within my source code or
when using my hivemind library within their own.
Those are a few off the top of my head. Not the kind of thing that
makes people swoon but definitely the kind of thing that makes me
happy when writing services.
> As far as I am aware, hivemind does a great job with dependancy
> injection, but doesn't offer the vast majority of other functionality
> available from spring - transaction management, quartz integration,
> aop integration, messaging, etc. I suppose I could use hivemind IOC
> to instantiate all the spring framework classes that provide the
> functionality I just listed, but that just seems like an obtuse
> solution, especially when it isn't clear (to me, at least) that the
> baseline IOC/dependancy injection code itself is particularly
> superior. They both accomplish the same tasks, and spring doesn't
> absolutely require an interface which is important when using
> libraries you don't control). Hivemind also has a much smaller
> community of users which is significant when building a sizeable
> engineering team.
>
This is true. Hivemind doesn't try to wrap every possible concrete
service type available. To unabashedly steal a phrase I heard once -
Spring is a framework for building applications, Hivemind is a
framework for building frameworks.
To be fair though, I've done much more "enterprise" development than I
have web and happened to have implemented the following Hivemind
services not too long ago very easily without using a single library
from Spring:
-) Quartz
-) Drools
-) JMS / ActiveMQ
-) Hibernate
-) Rmi transport
-) Integrated Tapestry/Hibernate transaction management.
-) Standalone appserver bootstrapping
Maybe there are others, probably I'm forgetting everything by now. I
can say that it's all been done in an extremely large enterprise
system that is deployed nationwide in critical care areas of
hospitals. The system also interfaces (transparently thanks to
hivemind) with so many different sources of data that I know I
wouldn't be able to remember them all if I tried. It's definitely
nearing 100's at a minimum.
> And really, even if it was just moving code into a config file that
> doesn't require recompilation, there are distinct advantages in having
> just that when architecting a project with 500,000+ lines of code and
> a team of 20 engineers. It means that I, as an architect, can manage
> transaction semantics for our entire suite of applications from a
> single location, rather than relying on 20 engineers who are 11 time
> zones and 6,000 miles away to get it right, or having to code review
> all those extra lines of code. Instead, my engineers worry about
> making sure the service method does what it claims it will, and I make
> sure that it participates in any necessary transaction correctly from
> the app context.
>
As for xml being easy to manage vs hard coded static strings or some
other unjarring form of non configurable option I can't argue with
that statement. I can say that there's not a single thing you can do
in Xml that I can't do with annotations. (except write more xml )
Annotations have the added benefit of carrying behavior with them.
Meaning that you can apply them in unexpected places and get the same
results. Transaction demarcation is nice, but really - wouldn't it be
nice to just be able to say @Transaction(<however you want to say
PROPOGATION_REQUIRED>) on a listener method and be done with it?
Doesn't mean you can't call services and have them participate in the
same transaction. Just means that you are putting the boundary where
it belongs. All without the author of the annotation having to know
how and where you might possibly apply it.
<snipped>
>
> --sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Re: Tapernate Access multiple database
Posted by Ma...@bmw.ch.
Hm, couldn't resist to drop a few remarks on that (inline):
> -----Original Message-----
> From: sgendler@gmail.com [mailto:sgendler@gmail.com] On
> Behalf Of Sam Gendler
> Sent: Wednesday, November 22, 2006 2:24 AM
> To: Tapestry users
> Subject: Re: Re: Tapernate Access multiple database
>
> Actually, Spring does so many things that hivemind doesn't
> (at least as far as I am aware), that you can't even compare
Spring does support stateful services? session-per-conversation?
As far as I know, it doesn't even have service-models.
> them. As for getting transactionality without writing code,
> I'd say there's no comparison between the single line of
> 'code' I have to add to an XML file in order to wrap a method
> in transaction semantics (including handling of rollbacks,
> using existing transaction or starting a new
> one) and having to manually add code to do the same thing on
> every service method, especially since I can use wildcards in
thats a bit of an odd comparison. If you can use a
Tapernate/Honeyomb-like
approach out-of-the box you need exactly ZERO lines of code per service
method
since it's just ta-per-request or per-conversation by default. Rollbacks
on Exception,
and the like is included, of course.
If you can't use it out-of-the-box, because you really need multiple
ta-resources, the alternative is not coding ta's manually, but doing
some not really complex changes to make tapernate/honeycomb handle
these.
> the XML file to handle multiple methods in the same manner.
> The fact that I can swap in and out JTA transactions,
> hibernate transactions, and JDBC transactions, again with
> only a single modification to an XML file, is a godsend as a
> project grows over the course of its use. When we went from
> one database to 2, and then 3, we didn't have to do anything
> but modify a config file to use J2EE transactions instead of
> the built in hibernate ones. There is just no comparison
> between the complexity of the application context file and
> the code it replaces.
I'd suspect, that most of that code is replaced by your container's
ta-manager, right? Spring, on it's own, does not do a lot in terms
of ta-coordination apart of letting you use it, when it's around.
>
> As far as I am aware, hivemind does a great job with
> dependancy injection, but doesn't offer the vast majority of
> other functionality available from spring - transaction
> management, quartz integration, aop integration, messaging,
> etc. I suppose I could use hivemind IOC to instantiate all
> the spring framework classes that provide the functionality I
> just listed, but that just seems like an obtuse solution,
> especially when it isn't clear (to me, at least) that the
> baseline IOC/dependancy injection code itself is particularly
> superior. They both accomplish the same tasks, and spring
> doesn't absolutely require an interface which is important
> when using libraries you don't control). Hivemind also has a
You don't need interfaces, bean-services are there since
HiveMind 1.1.1 (at least)
> much smaller community of users which is significant when
> building a sizeable engineering team.
>
> And really, even if it was just moving code into a config
> file that doesn't require recompilation, there are distinct
> advantages in having just that when architecting a project
> with 500,000+ lines of code and a team of 20 engineers. It
> means that I, as an architect, can manage transaction
> semantics for our entire suite of applications from a single
> location, rather than relying on 20 engineers who are 11 time
> zones and 6,000 miles away to get it right, or having to code
> review all those extra lines of code. Instead, my engineers
> worry about making sure the service method does what it
> claims it will, and I make sure that it participates in any
> necessary transaction correctly from the app context.
That's true to exactly the same extent for HiveMind-based solutions,
of course.
>
> Incidentally, I disagree that a single database is the minority case.
> That is true when talking about building an external facing
> website, but not at all true when building enterprise
> solutions. That's the whole reason the j2ee framework
> exists. A sizeable company may well have tens of databases
> that need to be integrated into internal applications, and
> pulling reports from a data warehouse isn't just common, it
> has been a requirement on nearly every project I've worked on
> in an enterprise context. Hell, in my current company, I've
> got data being fed to me from 4 different sources
> (salesforce.com, domain db, data warehouse, another 3rd party
> service), although I combine two into a single db. It is,
> however, probably the minority case for tapestry users, so
> I'm not saying tapernate went in the wrong direction on that
> point. Most apps complex enough to want multiple dbs
> probably aren't going to be looking at something like
> tapernate, anyway. I want more control than it offers me.
> Chicken or egg, I suppose.
Ironically, Tapernate IS just a convenient wrapper around the Spring
Hibernate/TA-management stuff ... That's about the only reason I,
personally
don't use it (until James comes up with his conversation support, at
least).
Additionally, If I need to use multiple db's, I really like to map the
foreign ones into the first one via updatable remote views /
materialised views.
That gives you the extra benefit of releasing the tight coupling, that
usually
goes with db-integration-patterns. And you get rid of costly two
phase-commit protocols
on the app-server level. And you can tune your performance by doing the
db-coupling
asynchronously (materialized views versus plain ones).
Marcus
>
> --sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: Tapernate Access multiple database
Posted by Sam Gendler <sg...@ideasculptor.com>.
On 11/21/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> I guess that depends on what you consider having to "write code" . All
> that xml is nice but seems to really have just moved the code to a new
> format that doesn't require re-compilation. I can't argue that spring
> isn't nice though, I just think hivemind is light years ahead of it.
> It's too bad that it's still in the stone ages when it comes to
> comparing them with documentation.
Actually, Spring does so many things that hivemind doesn't (at least
as far as I am aware), that you can't even compare them. As for
getting transactionality without writing code, I'd say there's no
comparison between the single line of 'code' I have to add to an XML
file in order to wrap a method in transaction semantics (including
handling of rollbacks, using existing transaction or starting a new
one) and having to manually add code to do the same thing on every
service method, especially since I can use wildcards in the XML file
to handle multiple methods in the same manner. The fact that I can
swap in and out JTA transactions, hibernate transactions, and JDBC
transactions, again with only a single modification to an XML file, is
a godsend as a project grows over the course of its use. When we went
from one database to 2, and then 3, we didn't have to do anything but
modify a config file to use J2EE transactions instead of the built in
hibernate ones. There is just no comparison between the complexity of
the application context file and the code it replaces.
As far as I am aware, hivemind does a great job with dependancy
injection, but doesn't offer the vast majority of other functionality
available from spring - transaction management, quartz integration,
aop integration, messaging, etc. I suppose I could use hivemind IOC
to instantiate all the spring framework classes that provide the
functionality I just listed, but that just seems like an obtuse
solution, especially when it isn't clear (to me, at least) that the
baseline IOC/dependancy injection code itself is particularly
superior. They both accomplish the same tasks, and spring doesn't
absolutely require an interface which is important when using
libraries you don't control). Hivemind also has a much smaller
community of users which is significant when building a sizeable
engineering team.
And really, even if it was just moving code into a config file that
doesn't require recompilation, there are distinct advantages in having
just that when architecting a project with 500,000+ lines of code and
a team of 20 engineers. It means that I, as an architect, can manage
transaction semantics for our entire suite of applications from a
single location, rather than relying on 20 engineers who are 11 time
zones and 6,000 miles away to get it right, or having to code review
all those extra lines of code. Instead, my engineers worry about
making sure the service method does what it claims it will, and I make
sure that it participates in any necessary transaction correctly from
the app context.
Incidentally, I disagree that a single database is the minority case.
That is true when talking about building an external facing website,
but not at all true when building enterprise solutions. That's the
whole reason the j2ee framework exists. A sizeable company may well
have tens of databases that need to be integrated into internal
applications, and pulling reports from a data warehouse isn't just
common, it has been a requirement on nearly every project I've worked
on in an enterprise context. Hell, in my current company, I've got
data being fed to me from 4 different sources (salesforce.com, domain
db, data warehouse, another 3rd party service), although I combine two
into a single db. It is, however, probably the minority case for
tapestry users, so I'm not saying tapernate went in the wrong
direction on that point. Most apps complex enough to want multiple
dbs probably aren't going to be looking at something like tapernate,
anyway. I want more control than it offers me. Chicken or egg, I
suppose.
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Access multiple database
Posted by Jesse Kuhnert <jk...@gmail.com>.
I guess that depends on what you consider having to "write code" . All
that xml is nice but seems to really have just moved the code to a new
format that doesn't require re-compilation. I can't argue that spring
isn't nice though, I just think hivemind is light years ahead of it.
It's too bad that it's still in the stone ages when it comes to
comparing them with documentation.
The new Tapestry IOC layer (that I'm assuming will find it's way into
a hivemind release in one form another) looks incredibly promising
though. No more having to look in xml files to see where things are
being used / tied ! Also has the benefit of being self documenting
with all of the tool support surrounding javadocs / etc..
On 11/20/06, Sam Gendler <sg...@ideasculptor.com> wrote:
<snipped>
> Honestly, I can't imagine a system of this complexity having a simpler
> interface since everything is done declaratively within the spring
> application context. There's not a single line of code devoted to
> dealing with multiple databases.
>
> --sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Access multiple database
Posted by James Carman <ja...@carmanconsulting.com>.
The majority of applications use one database, so Tapernate (actually
hivemind-hibernate3, which Tapernate is built upon) doesn't officially
support multiple databases. Tapernate allows you to just drop jars
into your classpath, which makes it very simple to use. It wouldn't
be so simple to set up if it had to try to keep track of multiple
databases. I went for simplicity rather than trying to make it cover
a minority case.
On 11/20/06, Sam Gendler <sg...@ideasculptor.com> wrote:
> On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> > Thank you. Did you come up with any solution without Tapernate?
> >
>
> This is relatively simple if you aren't using a framework that
> explicitly prevents it. I use swing + hibernate to provide all the
> layers to my app underneath the web layer and it is trivial to provide
> access to multiple databases. I can define multiple data sources in
> my application context and then provide dao beans which use the
> appropriate data sources as well as service objects which utilize
> those daos. My web layer isn't even aware of the location of data.
> It just calls a method in the service layer, which may use DAOs from
> multiple databases to accomplish the necessary work. And with
> spring's nice declarative transactions, it is easy, within the
> confines of a JTA transaction in a J2EE container, to have a single
> transaction span db access to multiple databases, which is really
> convenient.
>
> In my app, I have a situation where my entire domain model is provided
> via hibernate to a single domain db, but the huge volume of data that
> I need to provide access to for reporting is in 2 separate data
> warehouses. The domain entities are all accessed via DAO's using
> spring's built in hibernate dao support classes, and I use pure JDBC
> to access the 2 separate data warehouses. So I have about 25 DAOs
> using the hibernate data source (one for each entity), and one dao
> using one jdbc connection to the first warehouse and 3 separate DAOs
> using JDBC connections to the second warehouse. I have service
> objects which need to pass hibernate entities to the warehouse daos so
> that they can construct the correct SQL statements for building
> reports, so many of my service objects receive a reference to several
> hibernate DAOs as well as at least one jdbc dao. It works like a
> charm. All transactions are declared on service object methods, so
> transactions automatically encapsulate access to every database used
> by the service method, and my daos don't need to know a thing about
> transactions.
>
> Honestly, I can't imagine a system of this complexity having a simpler
> interface since everything is done declaratively within the spring
> application context. There's not a single line of code devoted to
> dealing with multiple databases.
>
> --sam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Access multiple database
Posted by Sam Gendler <sg...@ideasculptor.com>.
On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> Thank you. Did you come up with any solution without Tapernate?
>
This is relatively simple if you aren't using a framework that
explicitly prevents it. I use swing + hibernate to provide all the
layers to my app underneath the web layer and it is trivial to provide
access to multiple databases. I can define multiple data sources in
my application context and then provide dao beans which use the
appropriate data sources as well as service objects which utilize
those daos. My web layer isn't even aware of the location of data.
It just calls a method in the service layer, which may use DAOs from
multiple databases to accomplish the necessary work. And with
spring's nice declarative transactions, it is easy, within the
confines of a JTA transaction in a J2EE container, to have a single
transaction span db access to multiple databases, which is really
convenient.
In my app, I have a situation where my entire domain model is provided
via hibernate to a single domain db, but the huge volume of data that
I need to provide access to for reporting is in 2 separate data
warehouses. The domain entities are all accessed via DAO's using
spring's built in hibernate dao support classes, and I use pure JDBC
to access the 2 separate data warehouses. So I have about 25 DAOs
using the hibernate data source (one for each entity), and one dao
using one jdbc connection to the first warehouse and 3 separate DAOs
using JDBC connections to the second warehouse. I have service
objects which need to pass hibernate entities to the warehouse daos so
that they can construct the correct SQL statements for building
reports, so many of my service objects receive a reference to several
hibernate DAOs as well as at least one jdbc dao. It works like a
charm. All transactions are declared on service object methods, so
transactions automatically encapsulate access to every database used
by the service method, and my daos don't need to know a thing about
transactions.
Honestly, I can't imagine a system of this complexity having a simpler
interface since everything is done declaratively within the spring
application context. There's not a single line of code devoted to
dealing with multiple databases.
--sam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapernate Access multiple database
Posted by Henry Chen <he...@gmail.com>.
Thank you. Did you come up with any solution without Tapernate?
-----Original Message-----
From: Chris Chiappone [mailto:chiappone@gmail.com]
Sent: Thursday, November 16, 2006 10:57 AM
To: Tapestry users
Subject: Re: Tapernate Access multiple database
I has asked James about this a while back. Unfortunately i don't
believe there is any support in Tapernate for this.
On 11/16/06, Henry Chen <he...@gmail.com> wrote:
> Hi,
>
> Anybody use Tapernate to access multiple databases? How can I switch to
> another database in runtime? Thank you very much.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
~chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org