Hi Jukka,

I appreciate the input. You make a good point about the session lifespan in
contrast with desktop and web application paradigms. On my class example, if
I might defend my thinking a bit it seems like in larger systems, the
loosely typed nature of JCR objects (in particular Node and Property) could
become a problem. Unless these are wrapped with objects, I could imagine
there being many references to the same node in many places. 

For example, I need to change the underlying type of a property "myprop"
from Long to Double. If not wrapped, I'd have to hunt down cases of the
following throughout my application. 

Property p = node.getProperty("myprop");
Long l = p.getLong();

Unfortunately, this may not be written the same way every time, so it's
likely I miss a few instances and introduce bugs. With a wrapper around a
node, I'd change it in once place and the compiler would enforce the change
throughout the application for me based upon strongly typed references.

Aside from being strongly typed, I feel like it presents opportunities to
build in domain logic on top of my nodes. My example probably did a crummy
job of illustrating additional benefits, but one idea might be to have Album
implement a Comparable interface. Or maybe I might want to pass an album
into a RecordPlayer object. It just seems more OO friendly to me, although I
will concede it's going to be more work.



Jukka Zitting wrote:
> 
> Hi,
> 
> On Nov 7, 2007 12:38 PM, loproman <loproman@gmail.com> wrote:
>> What are your thoughts? Am I doing anything that might cause issues as
>> things get more complex? I'm new to the concept of JCR, so I'm very
>> interested in learning how I can use it in my code as naturally as
>> possible.
> 
> I wouldn't use your Album and Song classes as they are now, as their
> methods are essentially just wrappers around equivalent JCR methods.
> Such a data access layer is more useful for JDBC, where a method like
> Album.getName() could become:
> 
>        public String getName() throws SQLException {
>            PreparedStatement ps = connection.prepareStatement(
>                "SELECT name FROM albums WHERE albumid=?");
>            try {
>                ps.setString(1, albumid);
>                ResultSet rs = ps.executeQuery();
>                try {
>                    if (rs.next()) {
>                        return rs.getString(1);
>                    } else {
>                        ... // handle error
>                    }
>                } finally {
>                    rs.close();
>                }
>            } finally {
>                ps.close();
>            }
>        }
> 
> No wonder why frameworks like Hibernate are popular...
> 
>> Also, how long should sessions live? With relational databases, best
>> practice
>> is to open and close the connection as quickly as possible. However, it
>> seems
>> like JCR sessions can/should stay open much longer.
> 
> It depends on your application. A standalone client is probably best
> served with a single JCR session (just like a single JDBC connection
> would be a good idea), but a webapp serving multiple independent and
> concurrent requests should probably (unless it wants to leverage the
> transient space for handling unsaved changes) use a session pool or
> start separate sessions for each request.
> 
> BR,
> 
> Jukka Zitting
> 
> 

-- 
View this message in context: http://www.nabble.com/Jackrabbit-Best-Practices-Design-Patterns-tf4762615.html#a13636339
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.