Re: Alternative Datsource Hot-potatoing...

[Ted Husted]

Craig Tataryn wrote:


> Where I was getting lost was, how do I get a connection from the 
> connection pool all the way down to the bottom level Data layer object?  
> I think I have the answer in that I could just have a kind of central 
> static class that is initialized with the Struts Datasource on web app 
> startup, and the Datalayer objects that need to get a connection to a 
> database in order to manipulate data, could simply ask for it via the 
> static methods of this class.

That's exactly what I'm doing now for the same reasons. My core data 
access classes (StatementUtils) just take commands and parameters. All 
the JDBC work is out of view of the business classes. They just pass an 
command and an object to populate and get back an object or collection 
of objects. The business classes get the commands by passing a token to 
method that accesses a Properties file. Right now, the Properties file 
returns SQL commands, but if they needed to be something else, this 
could be changed without recoding the business classes. You'd have to 
import a different StatementUtils class, but so long as it used the same 
interface, it would plug and play.

-Ted.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Alternative Datsource Hot-potatoing...

[Ted Husted]

An underlying question may be whether a ConnectionAdaptor or a 
DataAdaptor is a business class. I believe it would really be a data 
access or resource-layer class that is provided for the use of business 
classes (or other data access class). Such an adaptor can be 
~configured~ with a DataSource that is then used (internally) to provide 
a connection to the business classes (a la Struts).

-Ted.

Craig R. McClanahan wrote:

> 
> On Fri, 6 Sep 2002, Craig Tataryn wrote:
> 
> 
>>Date: Fri, 06 Sep 2002 17:57:42 -0500
>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Alternative Datsource Hot-potatoing...
>>
>>Thanks Ted, I'll check it out.  But just out of curiosity, why would you
>>ever want your Business Layer to know about Datasources?
>>
>>Craig.
>>
> 
> This "Craig" stuff is going to get confusing :-).
> 
> The strategic issue, IMHO, is that you want business layer classes to know
> the absolute minimum information possible to achieve its objectives.  In
> the particular case at hand, the minimum possible knowledge would be
> what java.sql.Connection to use for their JDBC activities.  If you're in a
> batch-mode single threaded application, why would you want to go to all
> the effort to establish a DataSource object, when you'd only ever use a
> single Connection from it?  If you're going to pass in a reference to a
> JDBC-something object, it seems better to me that you pass a Connection
> instead -- that way a batch app can pass the one-and-only Connection it
> creates, and the business logic layer is none the wiser.
> 
> Craig (McClanahan :-)
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


-- 
Ted Husted, Husted dot Com, Fairport NY US
co-author, Java Web Development with Struts
Order it today:
<http://husted.com/struts/book.html>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Alternative Datsource Hot-potatoing...

[Craig Tataryn]

Let me add some context here:  :-)

And some more:

In our VB/COM app, our business layer never really knew where data was 
comming from.  And I'm not just talking about what "database" the data was 
coming from, I mean it didn't even know if the data was coming back from a 
flat file, a queue or a database.  We achieved this by only returning the 
serialized data of the object which were reinflated into our business 
objects upon retrieval, so it looked something like this.  And we made a 
little routing manager that figured out what DataObject should be 
instantiated for a business object.

Here is the definition for let's say the clsEmployee business object's 
retrieve function:

Public Sub Retrieve(EmpID as String)
Dim da as IDataObject
Dim rm as RoutingManager
Dim colFields as Collection
Dim colFilters as Collection
Dim vPropBag as Variant

'Ask the routing manager what data object to instantiate
Set rm = new RoutingManager
'this looks up in a map what the CLSID of the data object
'associated with the business object clsEmployee is, it then
'instantiates this object and passes it back. So, if sometime down
'the road we need to retrieve employees from an XML file, we would
'simply update the map that the routing manager feeds off of for the
'bEmployee.clsEmployee entry and point it to the new Dataobject.
Set da = rm.getDataObject("bEmployee.clsEmployee");
'
'build both the fields collection (i.e. the fields you want returned)
'and the filters collection. For this example we want to
'add empid = value to the filters collection, we never actually added
'sql stuff in the business layer, we just added tokens which were
'transformed into SQL (maybe) in the datalayer from the contents of
'the fields and filters collection
'.

'now ask the datalayer object to get us the object from the database
vPropBag = da.retrieve(colFields, colFilters)
'grab the non datasource centric property bag and have this object
'inflate itself with it
Me.Deserialize(vPropBag)

'we had to do all this messy serialization/deserialization because
'sending objects accross process or physical boundaries was not as
'straight forward in COM as it is in Java.  The vPropBag would most
'likely just be a buch of field=value strings, something COM serializes
'natively.

End Sub

So, barring all that, I could reuse this architecture above, coding a data 
object for each business object and having it grab data by whatever means 
necessary, and because it is so abstracted, I could write a dataobject to 
use the native API of a connection pool and never have to rewrite a Business 
object if the new Datastore were to change to an XML file (probably does not 
need a JDBC connection ;).

Where I was getting lost was, how do I get a connection from the connection 
pool all the way down to the bottom level Data layer object?  I think I have 
the answer in that I could just have a kind of central static class that is 
initialized with the Struts Datasource on web app startup, and the Datalayer 
objects that need to get a connection to a database in order to manipulate 
data, could simply ask for it via the static methods of this class.

Memories

Thanks!



P.S. I am without static IP, and thus computer-programmer.org tutorials are 
down.  I should be getting a static IP in about a week!  Hopefully by then I 
will have played around with 1.1 long enough to revise my tutorial!

>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Alternative Datsource Hot-potatoing...
>Date: Fri, 6 Sep 2002 19:32:17 -0700 (PDT)
>
>
>
>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>
> > Date: Fri, 06 Sep 2002 17:57:42 -0500
> > From: Craig Tataryn <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Alternative Datsource Hot-potatoing...
> >
> > Thanks Ted, I'll check it out.  But just out of curiosity, why would you
> > ever want your Business Layer to know about Datasources?
> >
> > Craig.
>
>This "Craig" stuff is going to get confusing :-).
>
>The strategic issue, IMHO, is that you want business layer classes to know
>the absolute minimum information possible to achieve its objectives.  In
>the particular case at hand, the minimum possible knowledge would be
>what java.sql.Connection to use for their JDBC activities.  If you're in a
>batch-mode single threaded application, why would you want to go to all
>the effort to establish a DataSource object, when you'd only ever use a
>single Connection from it?  If you're going 

Re: Alternative Datsource Hot-potatoing...

[Craig R. McClanahan]

On Fri, 6 Sep 2002, Phil Steitz wrote:

> Date: Fri, 06 Sep 2002 16:07:05 -0700
> From: Phil Steitz <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Alternative Datsource Hot-potatoing...
>
> Starting to look a lot like JNDI...(pronounced "Gin-dy", sung to a
> familiar tune)
>
> Seriously, look again at Craig M's option 3 -- if your container
> supports it, the lookup and implementation abstraction can be handled
> for you.
>

If you're using a J2EE app environment, this is true for "J2EE Client"
type applications as well.

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Alternative Datsource Hot-potatoing...

[Craig R. McClanahan]

On Fri, 6 Sep 2002, Craig Tataryn wrote:

> Date: Fri, 06 Sep 2002 17:57:42 -0500
> From: Craig Tataryn <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Alternative Datsource Hot-potatoing...
>
> Thanks Ted, I'll check it out.  But just out of curiosity, why would you
> ever want your Business Layer to know about Datasources?
>
> Craig.

This "Craig" stuff is going to get confusing :-).

The strategic issue, IMHO, is that you want business layer classes to know
the absolute minimum information possible to achieve its objectives.  In
the particular case at hand, the minimum possible knowledge would be
what java.sql.Connection to use for their JDBC activities.  If you're in a
batch-mode single threaded application, why would you want to go to all
the effort to establish a DataSource object, when you'd only ever use a
single Connection from it?  If you're going to pass in a reference to a
JDBC-something object, it seems better to me that you pass a Connection
instead -- that way a batch app can pass the one-and-only Connection it
creates, and the business logic layer is none the wiser.

Craig (McClanahan :-)



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Alternative Datsource Hot-potatoing...

[Ted Husted]

My business classes typically don't know anything about Datasources or 
JDBC or any of that. The business classes just hand up a token 
representing the data access command. The data access routines then use 
that to return a collection of beans.

But if you're asking DataSources versus Connections, it's because 
DataSources are advertised to the preferred method now. Given a 
DataSource, you can always get the connection. My JDBC access routines 
actually take a connection. The DataSoruce is just a means to an end.

-Ted.

Craig Tataryn wrote:

> Thanks Ted, I'll check it out.  But just out of curiosity, why would you 
> ever want your Business Layer to know about Datasources?
> 
> Craig.
> 
>> From: Ted Husted <[EMAIL PROTECTED]>
>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> Subject: Re: Alternative Datsource Hot-potatoing...
>> Date: Fri, 06 Sep 2002 17:27:12 -0400
>>
>> As mentioned elsewhere today, I've been using this ConnectionAdaptor:
>>
>> 
>http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/
> 
>>
>>
>> But I'd wouldn't mind refactoring it into more of a DataSource 
>> manager, with the functionality seen in Struts 1.1. The idea being you 
>> could register several different DataSources, and then have the 
>> business layer say I want this one, or just give me the default (null) 
>> one.
>>
>> -Ted
>>
>> Craig R. McClanahan wrote:
>>
>>>
>>> On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>>
>>>
>>>> Date: Fri, 06 Sep 2002 15:16:13 -0500
>>>> From: Craig Tataryn <[EMAIL PROTECTED]>
>>>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>> To: [EMAIL PROTECTED]
>>>> Subject: Re: Alternative Datsource Hot-potatoing...
>>>>
>>>> Thanks Craig.  I'll take a look into option 3.
>>>>
>>>> Could you see a problem with me creating a class called 
>>>> "DataAdaptor" with a
>>>> static method called "getConnection()" which is initialized apon 
>>>> application
>>>> startup with the DataSource setup by Struts?  Then using this static 
>>>> method
>>>> in my data objects to grab a connection?
>>>>
>>>>
>>>
>>> Isn't that basically option 2?
>>>
>>> The only disadvantage is that, unless you're careful, your DataAdaptor
>>> class will be dependent on Struts unless you make it have a static
>>> setDataSource() method or something.  But you're still tying your 
>>> business
>>> logic classes to the presence of DataAdaptor in every program that uses
>>> this approach (which may or may not be a big deal).
>>>
>>>
>>>> Craig.
>>>>
>>>
>>> Craig
>>>
>>>
>>>>> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>>>>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>> Subject: Re: Alternative Datsource Hot-potatoing...
>>>>> Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>>>>
>>>>>
>>>>>> Date: Fri, 06 Sep 2002 12:41:26 -0500
>>>>>> From: Craig Tataryn <[EMAIL PROTECTED]>
>>>>>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>>> To: [EMAIL PROTECTED]
>>>>>> Subject: Alternative Datsource Hot-potatoing...
>>>>>>
>>>>>> I was wondering if someone could give me a heads up on some 
>>>>>> alternative
>>>>>> means for which to give my data access layer access to my datasource.
>>>>>>
>>>>>> I don't really like the idea of my controller grabbing the 
>>>>>> Datasource,
>>>>>> passing it off to my business layer, who in turn passes it along 
>>>>>> to my
>>>>>>
>>>>> data
>>>>>
>>>>>> layer.  I guess I'm sort of a purest, but I don't think the Business
>>>>>>
>>>>> layer
>>>>>
>>>>>> should know anything ab

Re: Alternative Datsource Hot-potatoing...

[Phil Steitz]

Starting to look a lot like JNDI...(pronounced "Gin-dy", sung to a 
familiar tune)

Seriously, look again at Craig M's option 3 -- if your container 
supports it, the lookup and implementation abstraction can be handled 
for you.

Craig Tataryn wrote:
> 
> 
>> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> Isn't that basically option 2?
>>
>> The only disadvantage is that, unless you're careful, your DataAdaptor
>> class will be dependent on Struts unless you make it have a static
>> setDataSource() method or something.  But you're still tying your 
>> business
>> logic classes to the presence of DataAdaptor in every program that uses
>> this approach (which may or may not be a big deal).
>>
>> > Craig.
>>
> Number 2 was:
> * Static methods ... Most DB connection pool implementations offer a way
> to retrieve a DataSource or Connection via a static method.  Advantage:
> no handing around extra method parameters.  Disadvantage:  ties you to
> that connection pool's APIs.
> 
> I read this as I should use the static methods provided by the specific 
> connection pool.  What I meant was, I would create a generic 
> DataAdaptorFactory class and a DataAdaptor interface which could be be 
> configured off of a properties file to determine which data adaptor to 
> use. This way I can abstract myself from implementation details.
> 
> I don't think my business layer would even know about the DataAdaptor, 
> they would be communicating with my Data layer objects, which would take 
> care of data issues.
> 
> Something like:
> 
> public interface DataAdaptor {
> 
>   public java.sql.Connection getConnection();
> 
> }
> 
> public class DataAdaptorFactory {
> 
>   public static DataAdaptor getDataAdaptor() {
>   //lookup data adaptor implementation class
>   //in DataAdaptor.properties file
>   //do a class for name on that implemenation class
>   //return that class.
>   }
> }
> 
> DataAdaptor.properties:
> dataAdaptor=mypackage.MySqlDataAdaptor
> 
> public class MySqlDataAdaptor implements DataAdaptor {
> 
>public java.sql.Connection getConnection() {
>   //mysql specific stuff to get a connection
>}
> }
> 
> public class EmployeeDataObject {
>   public EmployeeList retrieve(String fields, String filters) {
>  DataAdaptor data = DataAdaptorFactory.getDataAdaptor();
>  Connection conn = data.getConnection();
>  //execute a query based on the fields and filters passed in
>  //transform the results to an 'EmployeeList' collection
>   }
> }
> 
> 
> Craig.
> 
>> Craig
>>
>> >
>> > >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> > >To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> > >Subject: Re: Alternative Datsource Hot-potatoing...
>> > >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>> > >
>> > >
>> > >
>> > >On Fri, 6 Sep 2002, Craig Tataryn wrote:
>> > >
>> > > > Date: Fri, 06 Sep 2002 12:41:26 -0500
>> > > > From: Craig Tataryn <[EMAIL PROTECTED]>
>> > > > Reply-To: Struts Users Mailing List 
>> <[EMAIL PROTECTED]>
>> > > > To: [EMAIL PROTECTED]
>> > > > Subject: Alternative Datsource Hot-potatoing...
>> > > >
>> > > > I was wondering if someone could give me a heads up on some 
>> alternative
>> > > > means for which to give my data access layer access to my 
>> datasource.
>> > > >
>> > > > I don't really like the idea of my controller grabbing the 
>> Datasource,
>> > > > passing it off to my business layer, who in turn passes it along 
>> to my
>> > >data
>> > > > layer.  I guess I'm sort of a purest, but I don't think the 
>> Business
>> > >layer
>> > > > should know anything about the database, and that means it 
>> shouldn't
>> > >even
>> > > > have methods that take connections or datasourses as parameters.
>> > > >
>> > > > I think the only thing I like about the Controller passing along a
>> > > > connection to my business/data layer is the fact that I can 
>> first open a
>> > > > transaction before passing the connection along, and then I can 
>> commit
>> > >the
>> > > > transaction when

Re: Alternative Datsource Hot-potatoing...

[Craig Tataryn]

I hear where you are coming from.  In the VB/COM app I was involved with, 
all our DB transactions were handled by MTS.  The stack thing seems 
interesting, but how do you allocate one stack per request?

You wouldn't happen to be able to share any of the code you speak about in 
your 2nd method can you?

Thanks,

Craig.

>From: "Philip S. Constantinou" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: Re: Alternative Datsource Hot-potatoing...
>Date: Fri, 6 Sep 2002 14:27:21 -0700
>
>I've been grappling with this myself and I came across a couple other 
>issues which may be worth consideration.
>
>I thought that it was import for my business methods to be re-entrant and 
>support transactions appropriately. This seems to be one of EJB's 
>successes. A practical scenario is: the controller calls method A which 
>calls method B; the controller also calls B directly. Each method may begin 
>a transaction if it's a new request from the application, but should only 
>commit the transaction and return the connection back to the connection 
>pool once the control is passed back to the application.
>
>Passing the connection in at the application layer does seem to address the 
>problem but doesn't separate concerns particularly well.
>
>I considered two other options:
>1) a proxy which maintains a reference to the connection pool and handles 
>getting and releasing the connection from the connection pool; or
>2) The solution I've settled on for the moment is having the business 
>methods have access to a connection pool and manage getting and releasing 
>the connection by using a stack based reference counting scheme. The 
>beginning of each transactional method starts with beginTransaction() and 
>ends with finally {endTransaction();}, from within the transaction 
>getConnection() always returns the same connection if the requesting thread 
>is the same.
>
>Both of these methods insure that each individual controller-request has 
>access to the same connection for all database requests yet doesn't require 
>the controller to specifically pass requests.
>
>The more I work on this kind of thing, the more I appreciate EJB... 
>something that I thought I'd never say.
>
>- Original Message -
>From: "Craig Tataryn" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, September 06, 2002 1:16 PM
>Subject: Re: Alternative Datsource Hot-potatoing...
>
>
> > Thanks Craig.  I'll take a look into option 3.
> >
> > Could you see a problem with me creating a class called "DataAdaptor" 
>with a
> > static method called "getConnection()" which is initialized apon 
>application
> > startup with the DataSource setup by Struts?  Then using this static 
>method
> > in my data objects to grab a connection?
> >
> > Craig.
> >
> > >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > >Subject: Re: Alternative Datsource Hot-potatoing...
> > >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> > >
> > >
> > >
> > >On Fri, 6 Sep 2002, Craig Tataryn wrote:
> > >
> > > > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > > > From: Craig Tataryn <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Alternative Datsource Hot-potatoing...
> > > >
> > > > I was wondering if someone could give me a heads up on some 
>alternative
> > > > means for which to give my data access layer access to my 
>datasource.
> > > >
> > > > I don't really like the idea of my controller grabbing the 
>Datasource,
> > > > passing it off to my business layer, who in turn passes it along to 
>my
> > >data
> > > > layer.  I guess I'm sort of a purest, but I don't think the Business
> > >layer
> > > > should know anything about the database, and that means it shouldn't
> > >even
> > > > have methods that take connections or datasourses as parameters.
> > > >
> > > > I think the only thing I like about the Controller passing along a
> > > > connection to my business/data layer is the fact that I can first 
>open a
> > > > transaction before passing 

Re: Alternative Datsource Hot-potatoing...

[Craig Tataryn]

Thanks Ted, I'll check it out.  But just out of curiosity, why would you 
ever want your Business Layer to know about Datasources?

Craig.

>From: Ted Husted <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Alternative Datsource Hot-potatoing...
>Date: Fri, 06 Sep 2002 17:27:12 -0400
>
>As mentioned elsewhere today, I've been using this ConnectionAdaptor:
>
>http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/
>
>But I'd wouldn't mind refactoring it into more of a DataSource manager, 
>with the functionality seen in Struts 1.1. The idea being you could 
>register several different DataSources, and then have the business layer 
>say I want this one, or just give me the default (null) one.
>
>-Ted
>
>Craig R. McClanahan wrote:
>
>>
>>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>
>>
>>>Date: Fri, 06 Sep 2002 15:16:13 -0500
>>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: Alternative Datsource Hot-potatoing...
>>>
>>>Thanks Craig.  I'll take a look into option 3.
>>>
>>>Could you see a problem with me creating a class called "DataAdaptor" 
>>>with a
>>>static method called "getConnection()" which is initialized apon 
>>>application
>>>startup with the DataSource setup by Struts?  Then using this static 
>>>method
>>>in my data objects to grab a connection?
>>>
>>>
>>
>>Isn't that basically option 2?
>>
>>The only disadvantage is that, unless you're careful, your DataAdaptor
>>class will be dependent on Struts unless you make it have a static
>>setDataSource() method or something.  But you're still tying your business
>>logic classes to the presence of DataAdaptor in every program that uses
>>this approach (which may or may not be a big deal).
>>
>>
>>>Craig.
>>>
>>
>>Craig
>>
>>
>>>>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>>>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>Subject: Re: Alternative Datsource Hot-potatoing...
>>>>Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>>>>
>>>>
>>>>
>>>>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>>>
>>>>
>>>>>Date: Fri, 06 Sep 2002 12:41:26 -0500
>>>>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>>>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>>To: [EMAIL PROTECTED]
>>>>>Subject: Alternative Datsource Hot-potatoing...
>>>>>
>>>>>I was wondering if someone could give me a heads up on some alternative
>>>>>means for which to give my data access layer access to my datasource.
>>>>>
>>>>>I don't really like the idea of my controller grabbing the Datasource,
>>>>>passing it off to my business layer, who in turn passes it along to my
>>>>>
>>>>data
>>>>
>>>>>layer.  I guess I'm sort of a purest, but I don't think the Business
>>>>>
>>>>layer
>>>>
>>>>>should know anything about the database, and that means it shouldn't
>>>>>
>>>>even
>>>>
>>>>>have methods that take connections or datasourses as parameters.
>>>>>
>>>>>I think the only thing I like about the Controller passing along a
>>>>>connection to my business/data layer is the fact that I can first open 
>>>>>a
>>>>>transaction before passing the connection along, and then I can commit
>>>>>
>>>>the
>>>>
>>>>>transaction when everything is done.  Thus my transactions are at the
>>>>>controller level, and can be managed there.
>>>>>
>>>>>Back in my old VB/COM days, we had a sort of DB Utilities class which
>>>>>
>>>>could
>>>>
>>>>>be accessed from the datalayer.  You would ask it to give you a
>>>>>
>>>>connection,
>>>>
>>>>>and it would get it for you.  Should I make my 

Re: Alternative Datsource Hot-potatoing...

[Craig Tataryn]

>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Isn't that basically option 2?
>
>The only disadvantage is that, unless you're careful, your DataAdaptor
>class will be dependent on Struts unless you make it have a static
>setDataSource() method or something.  But you're still tying your business
>logic classes to the presence of DataAdaptor in every program that uses
>this approach (which may or may not be a big deal).
>
> > Craig.
>
Number 2 was:
* Static methods ... Most DB connection pool implementations offer a way
to retrieve a DataSource or Connection via a static method.  Advantage:
no handing around extra method parameters.  Disadvantage:  ties you to
that connection pool's APIs.

I read this as I should use the static methods provided by the specific 
connection pool.  What I meant was, I would create a generic 
DataAdaptorFactory class and a DataAdaptor interface which could be be 
configured off of a properties file to determine which data adaptor to use. 
This way I can abstract myself from implementation details.

I don't think my business layer would even know about the DataAdaptor, they 
would be communicating with my Data layer objects, which would take care of 
data issues.

Something like:

public interface DataAdaptor {

   public java.sql.Connection getConnection();

}

public class DataAdaptorFactory {

   public static DataAdaptor getDataAdaptor() {
   //lookup data adaptor implementation class
   //in DataAdaptor.properties file
   //do a class for name on that implemenation class
   //return that class.
   }
}

DataAdaptor.properties:
dataAdaptor=mypackage.MySqlDataAdaptor

public class MySqlDataAdaptor implements DataAdaptor {

public java.sql.Connection getConnection() {
   //mysql specific stuff to get a connection
}
}

public class EmployeeDataObject {
   public EmployeeList retrieve(String fields, String filters) {
  DataAdaptor data = DataAdaptorFactory.getDataAdaptor();
  Connection conn = data.getConnection();
  //execute a query based on the fields and filters passed in
  //transform the results to an 'EmployeeList' collection
   }
}


Craig.

>Craig
>
> >
> > >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > >Subject: Re: Alternative Datsource Hot-potatoing...
> > >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> > >
> > >
> > >
> > >On Fri, 6 Sep 2002, Craig Tataryn wrote:
> > >
> > > > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > > > From: Craig Tataryn <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Alternative Datsource Hot-potatoing...
> > > >
> > > > I was wondering if someone could give me a heads up on some 
>alternative
> > > > means for which to give my data access layer access to my 
>datasource.
> > > >
> > > > I don't really like the idea of my controller grabbing the 
>Datasource,
> > > > passing it off to my business layer, who in turn passes it along to 
>my
> > >data
> > > > layer.  I guess I'm sort of a purest, but I don't think the Business
> > >layer
> > > > should know anything about the database, and that means it shouldn't
> > >even
> > > > have methods that take connections or datasourses as parameters.
> > > >
> > > > I think the only thing I like about the Controller passing along a
> > > > connection to my business/data layer is the fact that I can first 
>open a
> > > > transaction before passing the connection along, and then I can 
>commit
> > >the
> > > > transaction when everything is done.  Thus my transactions are at 
>the
> > > > controller level, and can be managed there.
> > > >
> > > > Back in my old VB/COM days, we had a sort of DB Utilities class 
>which
> > >could
> > > > be accessed from the datalayer.  You would ask it to give you a
> > >connection,
> > > > and it would get it for you.  Should I make my own class for 
>datasource
> > > > access which is intitalized upon application start with the 
>Datasource
> > > > object found by struts?  Then the rest of my datalayer can simply 
>use
> > >it?
> > > >
> > >
> > >Three basic options exist:
> > >
> > >* Hand a DataSource (I normally 

RE: Alternative Datsource Hot-potatoing...

[Martin Cooper]

I have something similar, but with another layer on top of it. My app has an
interesting requirement in that the data can potentially be split across
multiple physical databases and/or file groups (but need not be). Further,
the division can be modified after deployment.

To handle that, I have an extra layer that maps a "sub-schema name" to a
DataSource name. This way, my business layer asks for a database provider by
sub-schema name, and from that, it can obtain connections for the
appropriate database without having to know anything about which physical
database it is actually using. If the location of part of the database
changes, all I have to modify is the sub-schema name <-> data source name
mapping - the business layer doesn't care.

This may be more than anyone else needs, but I just thought I'd throw the
idea out there...

--
Martin Cooper


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 2:27 PM
> To: Struts Users Mailing List
> Subject: Re: Alternative Datsource Hot-potatoing...
> 
> 
> As mentioned elsewhere today, I've been using this ConnectionAdaptor:
> 
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaf
fold/src/java/org/apache/commons/scaffold/sql/
> 
> But I'd wouldn't mind refactoring it into more of a 
> DataSource manager, 
> with the functionality seen in Struts 1.1. The idea being you could 
> register several different DataSources, and then have the 
> business layer 
> say I want this one, or just give me the default (null) one.
> 
> -Ted
> 
> Craig R. McClanahan wrote:
> 
> > 
> > On Fri, 6 Sep 2002, Craig Tataryn wrote:
> > 
> > 
> >>Date: Fri, 06 Sep 2002 15:16:13 -0500
> >>From: Craig Tataryn <[EMAIL PROTECTED]>
> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: Alternative Datsource Hot-potatoing...
> >>
> >>Thanks Craig.  I'll take a look into option 3.
> >>
> >>Could you see a problem with me creating a class called 
> "DataAdaptor" with a
> >>static method called "getConnection()" which is initialized 
> apon application
> >>startup with the DataSource setup by Struts?  Then using 
> this static method
> >>in my data objects to grab a connection?
> >>
> >>
> > 
> > Isn't that basically option 2?
> > 
> > The only disadvantage is that, unless you're careful, your 
> DataAdaptor
> > class will be dependent on Struts unless you make it have a static
> > setDataSource() method or something.  But you're still 
> tying your business
> > logic classes to the presence of DataAdaptor in every 
> program that uses
> > this approach (which may or may not be a big deal).
> > 
> > 
> >>Craig.
> >>
> > 
> > Craig
> > 
> > 
> >>>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >>>Reply-To: "Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> >>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>>Subject: Re: Alternative Datsource Hot-potatoing...
> >>>Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> >>>
> >>>
> >>>
> >>>On Fri, 6 Sep 2002, Craig Tataryn wrote:
> >>>
> >>>
> >>>>Date: Fri, 06 Sep 2002 12:41:26 -0500
> >>>>From: Craig Tataryn <[EMAIL PROTECTED]>
> >>>>Reply-To: Struts Users Mailing List 
> <[EMAIL PROTECTED]>
> >>>>To: [EMAIL PROTECTED]
> >>>>Subject: Alternative Datsource Hot-potatoing...
> >>>>
> >>>>I was wondering if someone could give me a heads up on 
> some alternative
> >>>>means for which to give my data access layer access to my 
> datasource.
> >>>>
> >>>>I don't really like the idea of my controller grabbing 
> the Datasource,
> >>>>passing it off to my business layer, who in turn passes 
> it along to my
> >>>>
> >>>data
> >>>
> >>>>layer.  I guess I'm sort of a purest, but I don't think 
> the Business
> >>>>
> >>>layer
> >>>
> >>>>should know anything about the database, and that means 
> it shouldn't
> >>>>
> >>>even
> >>>
> >>>>have methods that take connections or datasourses as parameters.
> >>>>
> >>>>I think the only thing I like 

Re: Alternative Datsource Hot-potatoing...

[Philip S. Constantinou]

I've been grappling with this myself and I came across a couple other issues which may 
be worth consideration.

I thought that it was import for my business methods to be re-entrant and support 
transactions appropriately. This seems to be one of EJB's successes. A practical 
scenario is: the controller calls method A which calls method B; the controller also 
calls B directly. Each method may begin a transaction if it's a new request from the 
application, but should only commit the transaction and return the connection back to 
the connection pool once the control is passed back to the application. 

Passing the connection in at the application layer does seem to address the problem 
but doesn't separate concerns particularly well. 

I considered two other options:
1) a proxy which maintains a reference to the connection pool and handles getting and 
releasing the connection from the connection pool; or
2) The solution I've settled on for the moment is having the business methods have 
access to a connection pool and manage getting and releasing the connection by using a 
stack based reference counting scheme. The beginning of each transactional method 
starts with beginTransaction() and ends with finally {endTransaction();}, from within 
the transaction getConnection() always returns the same connection if the requesting 
thread is the same. 

Both of these methods insure that each individual controller-request has access to the 
same connection for all database requests yet doesn't require the controller to 
specifically pass requests.

The more I work on this kind of thing, the more I appreciate EJB... something that I 
thought I'd never say.

- Original Message - 
From: "Craig Tataryn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 06, 2002 1:16 PM
Subject: Re: Alternative Datsource Hot-potatoing...


> Thanks Craig.  I'll take a look into option 3.
> 
> Could you see a problem with me creating a class called "DataAdaptor" with a 
> static method called "getConnection()" which is initialized apon application 
> startup with the DataSource setup by Struts?  Then using this static method 
> in my data objects to grab a connection?
> 
> Craig.
> 
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >Subject: Re: Alternative Datsource Hot-potatoing...
> >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> >
> >
> >
> >On Fri, 6 Sep 2002, Craig Tataryn wrote:
> >
> > > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > > From: Craig Tataryn <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Alternative Datsource Hot-potatoing...
> > >
> > > I was wondering if someone could give me a heads up on some alternative
> > > means for which to give my data access layer access to my datasource.
> > >
> > > I don't really like the idea of my controller grabbing the Datasource,
> > > passing it off to my business layer, who in turn passes it along to my 
> >data
> > > layer.  I guess I'm sort of a purest, but I don't think the Business 
> >layer
> > > should know anything about the database, and that means it shouldn't 
> >even
> > > have methods that take connections or datasourses as parameters.
> > >
> > > I think the only thing I like about the Controller passing along a
> > > connection to my business/data layer is the fact that I can first open a
> > > transaction before passing the connection along, and then I can commit 
> >the
> > > transaction when everything is done.  Thus my transactions are at the
> > > controller level, and can be managed there.
> > >
> > > Back in my old VB/COM days, we had a sort of DB Utilities class which 
> >could
> > > be accessed from the datalayer.  You would ask it to give you a 
> >connection,
> > > and it would get it for you.  Should I make my own class for datasource
> > > access which is intitalized upon application start with the Datasource
> > > object found by struts?  Then the rest of my datalayer can simply use 
> >it?
> > >
> >
> >Three basic options exist:
> >
> >* Hand a DataSource (I normally prefer to send a Connection instead, but
> >   either works) to your business logic method as a parameter to each call
> >   that needs it.  Advantage:  no binding to anything.  Disadvantage:  can
> >   be a pain to han

Re: Alternative Datsource Hot-potatoing...

[Ted Husted]

As mentioned elsewhere today, I've been using this ConnectionAdaptor:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/

But I'd wouldn't mind refactoring it into more of a DataSource manager, 
with the functionality seen in Struts 1.1. The idea being you could 
register several different DataSources, and then have the business layer 
say I want this one, or just give me the default (null) one.

-Ted

Craig R. McClanahan wrote:

> 
> On Fri, 6 Sep 2002, Craig Tataryn wrote:
> 
> 
>>Date: Fri, 06 Sep 2002 15:16:13 -0500
>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Alternative Datsource Hot-potatoing...
>>
>>Thanks Craig.  I'll take a look into option 3.
>>
>>Could you see a problem with me creating a class called "DataAdaptor" with a
>>static method called "getConnection()" which is initialized apon application
>>startup with the DataSource setup by Struts?  Then using this static method
>>in my data objects to grab a connection?
>>
>>
> 
> Isn't that basically option 2?
> 
> The only disadvantage is that, unless you're careful, your DataAdaptor
> class will be dependent on Struts unless you make it have a static
> setDataSource() method or something.  But you're still tying your business
> logic classes to the presence of DataAdaptor in every program that uses
> this approach (which may or may not be a big deal).
> 
> 
>>Craig.
>>
> 
> Craig
> 
> 
>>>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>Subject: Re: Alternative Datsource Hot-potatoing...
>>>Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>>>
>>>
>>>
>>>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>>>
>>>
>>>>Date: Fri, 06 Sep 2002 12:41:26 -0500
>>>>From: Craig Tataryn <[EMAIL PROTECTED]>
>>>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Alternative Datsource Hot-potatoing...
>>>>
>>>>I was wondering if someone could give me a heads up on some alternative
>>>>means for which to give my data access layer access to my datasource.
>>>>
>>>>I don't really like the idea of my controller grabbing the Datasource,
>>>>passing it off to my business layer, who in turn passes it along to my
>>>>
>>>data
>>>
>>>>layer.  I guess I'm sort of a purest, but I don't think the Business
>>>>
>>>layer
>>>
>>>>should know anything about the database, and that means it shouldn't
>>>>
>>>even
>>>
>>>>have methods that take connections or datasourses as parameters.
>>>>
>>>>I think the only thing I like about the Controller passing along a
>>>>connection to my business/data layer is the fact that I can first open a
>>>>transaction before passing the connection along, and then I can commit
>>>>
>>>the
>>>
>>>>transaction when everything is done.  Thus my transactions are at the
>>>>controller level, and can be managed there.
>>>>
>>>>Back in my old VB/COM days, we had a sort of DB Utilities class which
>>>>
>>>could
>>>
>>>>be accessed from the datalayer.  You would ask it to give you a
>>>>
>>>connection,
>>>
>>>>and it would get it for you.  Should I make my own class for datasource
>>>>access which is intitalized upon application start with the Datasource
>>>>object found by struts?  Then the rest of my datalayer can simply use
>>>>
>>>it?
>>>
>>>Three basic options exist:
>>>
>>>* Hand a DataSource (I normally prefer to send a Connection instead, but
>>>  either works) to your business logic method as a parameter to each call
>>>  that needs it.  Advantage:  no binding to anything.  Disadvantage:  can
>>>  be a pain to hand it around.
>>>
>>>* Static methods ... Most DB connection pool implementations offer a way
>>>  to retrieve a DataSource or Connection via a static method.  Advantage:
>>>  no handing around extra method parameters.  Disadvantage:  ties you to
>>>  t

Re: Alternative Datsource Hot-potatoing...

[Craig R. McClanahan]

On Fri, 6 Sep 2002, Craig Tataryn wrote:

> Date: Fri, 06 Sep 2002 15:16:13 -0500
> From: Craig Tataryn <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Alternative Datsource Hot-potatoing...
>
> Thanks Craig.  I'll take a look into option 3.
>
> Could you see a problem with me creating a class called "DataAdaptor" with a
> static method called "getConnection()" which is initialized apon application
> startup with the DataSource setup by Struts?  Then using this static method
> in my data objects to grab a connection?
>

Isn't that basically option 2?

The only disadvantage is that, unless you're careful, your DataAdaptor
class will be dependent on Struts unless you make it have a static
setDataSource() method or something.  But you're still tying your business
logic classes to the presence of DataAdaptor in every program that uses
this approach (which may or may not be a big deal).

> Craig.

Craig

>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >Subject: Re: Alternative Datsource Hot-potatoing...
> >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> >
> >
> >
> >On Fri, 6 Sep 2002, Craig Tataryn wrote:
> >
> > > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > > From: Craig Tataryn <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Alternative Datsource Hot-potatoing...
> > >
> > > I was wondering if someone could give me a heads up on some alternative
> > > means for which to give my data access layer access to my datasource.
> > >
> > > I don't really like the idea of my controller grabbing the Datasource,
> > > passing it off to my business layer, who in turn passes it along to my
> >data
> > > layer.  I guess I'm sort of a purest, but I don't think the Business
> >layer
> > > should know anything about the database, and that means it shouldn't
> >even
> > > have methods that take connections or datasourses as parameters.
> > >
> > > I think the only thing I like about the Controller passing along a
> > > connection to my business/data layer is the fact that I can first open a
> > > transaction before passing the connection along, and then I can commit
> >the
> > > transaction when everything is done.  Thus my transactions are at the
> > > controller level, and can be managed there.
> > >
> > > Back in my old VB/COM days, we had a sort of DB Utilities class which
> >could
> > > be accessed from the datalayer.  You would ask it to give you a
> >connection,
> > > and it would get it for you.  Should I make my own class for datasource
> > > access which is intitalized upon application start with the Datasource
> > > object found by struts?  Then the rest of my datalayer can simply use
> >it?
> > >
> >
> >Three basic options exist:
> >
> >* Hand a DataSource (I normally prefer to send a Connection instead, but
> >   either works) to your business logic method as a parameter to each call
> >   that needs it.  Advantage:  no binding to anything.  Disadvantage:  can
> >   be a pain to hand it around.
> >
> >* Static methods ... Most DB connection pool implementations offer a way
> >   to retrieve a DataSource or Connection via a static method.  Advantage:
> >   no handing around extra method parameters.  Disadvantage:  ties you to
> >   that connection pool's APIs.
> >
> >* JNDI resources -- All J2EE app servers (and some servlet containers like
> >   Tomcat 4) offer support for JNDI resources that are accessible to your
> >   business logic directly like this:
> >
> > import javax.naming.Context;
> > import javax.naming.InitialContext;
> >
> > InitialContext ic = new InitialContext();
> > Context ctx = (Context) ic.lookup("java:comp/env");
> > DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");
> >
> >   where "jdbc/EmployeeDb" is a resource reference you have declared in
> >   your web.xml file.  Advantage:  No parameter passing, no connection
> >   pool API lock-in.  Advantage:  configuration of the data source is
> >   external to your webapp (it's done with the server configuration
> >   capabilities).  Disadvan

Re: Alternative Datsource Hot-potatoing...

[Craig Tataryn]

Thanks Craig.  I'll take a look into option 3.

Could you see a problem with me creating a class called "DataAdaptor" with a 
static method called "getConnection()" which is initialized apon application 
startup with the DataSource setup by Struts?  Then using this static method 
in my data objects to grab a connection?

Craig.

>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Alternative Datsource Hot-potatoing...
>Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
>
>
>
>On Fri, 6 Sep 2002, Craig Tataryn wrote:
>
> > Date: Fri, 06 Sep 2002 12:41:26 -0500
> > From: Craig Tataryn <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Alternative Datsource Hot-potatoing...
> >
> > I was wondering if someone could give me a heads up on some alternative
> > means for which to give my data access layer access to my datasource.
> >
> > I don't really like the idea of my controller grabbing the Datasource,
> > passing it off to my business layer, who in turn passes it along to my 
>data
> > layer.  I guess I'm sort of a purest, but I don't think the Business 
>layer
> > should know anything about the database, and that means it shouldn't 
>even
> > have methods that take connections or datasourses as parameters.
> >
> > I think the only thing I like about the Controller passing along a
> > connection to my business/data layer is the fact that I can first open a
> > transaction before passing the connection along, and then I can commit 
>the
> > transaction when everything is done.  Thus my transactions are at the
> > controller level, and can be managed there.
> >
> > Back in my old VB/COM days, we had a sort of DB Utilities class which 
>could
> > be accessed from the datalayer.  You would ask it to give you a 
>connection,
> > and it would get it for you.  Should I make my own class for datasource
> > access which is intitalized upon application start with the Datasource
> > object found by struts?  Then the rest of my datalayer can simply use 
>it?
> >
>
>Three basic options exist:
>
>* Hand a DataSource (I normally prefer to send a Connection instead, but
>   either works) to your business logic method as a parameter to each call
>   that needs it.  Advantage:  no binding to anything.  Disadvantage:  can
>   be a pain to hand it around.
>
>* Static methods ... Most DB connection pool implementations offer a way
>   to retrieve a DataSource or Connection via a static method.  Advantage:
>   no handing around extra method parameters.  Disadvantage:  ties you to
>   that connection pool's APIs.
>
>* JNDI resources -- All J2EE app servers (and some servlet containers like
>   Tomcat 4) offer support for JNDI resources that are accessible to your
>   business logic directly like this:
>
> import javax.naming.Context;
> import javax.naming.InitialContext;
>
> InitialContext ic = new InitialContext();
> Context ctx = (Context) ic.lookup("java:comp/env");
> DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");
>
>   where "jdbc/EmployeeDb" is a resource reference you have declared in
>   your web.xml file.  Advantage:  No parameter passing, no connection
>   pool API lock-in.  Advantage:  configuration of the data source is
>   external to your webapp (it's done with the server configuration
>   capabilities).  Disadvantage:  container must support this.
>
>For info on how to use the third option in Tomcat, see:
>
>   
>http://jakarata.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
>
>(NOTE -- if you're going to use Tomcat, definitely go for 4.1; 4.0's
>support has problems for many users).
>
> > Thanks,
> >
> > Craig.
> >
> > Craig W. Tataryn
> > Programmer/Analyst
> > Compuware
>
>Craig
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>


Craig W. Tataryn
Programmer/Analyst
Compuware

_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Alternative Datsource Hot-potatoing...

[Craig R. McClanahan]

On Fri, 6 Sep 2002, Craig Tataryn wrote:

> Date: Fri, 06 Sep 2002 12:41:26 -0500
> From: Craig Tataryn <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Alternative Datsource Hot-potatoing...
>
> I was wondering if someone could give me a heads up on some alternative
> means for which to give my data access layer access to my datasource.
>
> I don't really like the idea of my controller grabbing the Datasource,
> passing it off to my business layer, who in turn passes it along to my data
> layer.  I guess I'm sort of a purest, but I don't think the Business layer
> should know anything about the database, and that means it shouldn't even
> have methods that take connections or datasourses as parameters.
>
> I think the only thing I like about the Controller passing along a
> connection to my business/data layer is the fact that I can first open a
> transaction before passing the connection along, and then I can commit the
> transaction when everything is done.  Thus my transactions are at the
> controller level, and can be managed there.
>
> Back in my old VB/COM days, we had a sort of DB Utilities class which could
> be accessed from the datalayer.  You would ask it to give you a connection,
> and it would get it for you.  Should I make my own class for datasource
> access which is intitalized upon application start with the Datasource
> object found by struts?  Then the rest of my datalayer can simply use it?
>

Three basic options exist:

* Hand a DataSource (I normally prefer to send a Connection instead, but
  either works) to your business logic method as a parameter to each call
  that needs it.  Advantage:  no binding to anything.  Disadvantage:  can
  be a pain to hand it around.

* Static methods ... Most DB connection pool implementations offer a way
  to retrieve a DataSource or Connection via a static method.  Advantage:
  no handing around extra method parameters.  Disadvantage:  ties you to
  that connection pool's APIs.

* JNDI resources -- All J2EE app servers (and some servlet containers like
  Tomcat 4) offer support for JNDI resources that are accessible to your
  business logic directly like this:

import javax.naming.Context;
import javax.naming.InitialContext;

InitialContext ic = new InitialContext();
Context ctx = (Context) ic.lookup("java:comp/env");
DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");

  where "jdbc/EmployeeDb" is a resource reference you have declared in
  your web.xml file.  Advantage:  No parameter passing, no connection
  pool API lock-in.  Advantage:  configuration of the data source is
  external to your webapp (it's done with the server configuration
  capabilities).  Disadvantage:  container must support this.

For info on how to use the third option in Tomcat, see:

  http://jakarata.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html

(NOTE -- if you're going to use Tomcat, definitely go for 4.1; 4.0's
support has problems for many users).

> Thanks,
>
> Craig.
>
> Craig W. Tataryn
> Programmer/Analyst
> Compuware

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Alternative Datsource Hot-potatoing...

[Craig Tataryn]

I was wondering if someone could give me a heads up on some alternative 
means for which to give my data access layer access to my datasource.

I don't really like the idea of my controller grabbing the Datasource, 
passing it off to my business layer, who in turn passes it along to my data 
layer.  I guess I'm sort of a purest, but I don't think the Business layer 
should know anything about the database, and that means it shouldn't even 
have methods that take connections or datasourses as parameters.

I think the only thing I like about the Controller passing along a 
connection to my business/data layer is the fact that I can first open a 
transaction before passing the connection along, and then I can commit the 
transaction when everything is done.  Thus my transactions are at the 
controller level, and can be managed there.

Back in my old VB/COM days, we had a sort of DB Utilities class which could 
be accessed from the datalayer.  You would ask it to give you a connection, 
and it would get it for you.  Should I make my own class for datasource 
access which is intitalized upon application start with the Datasource 
object found by struts?  Then the rest of my datalayer can simply use it?

Thanks,

Craig.

Craig W. Tataryn
Programmer/Analyst
Compuware

_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: