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 <[EMAIL PROTECTED]> 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.
