Hmm.

The motivations for attaching the session to a thread local were:-

1. It avoids having to pass a connection variable everywhere. In a
database application virtually everything needs to interact with the
database so the extra parameter is a pain.

2. More importantly it makes the threading model clear -- one thread
per connection. Particularly in the early days of Orms people did
bad things with sharing Jdbc connections between threads.

3. I makes the code slightly shorter.

But that said, it is unusual, and unusual is bad. And it does
conflict with our new idea of detached data sets.

So... if you want to we could separate the code like you suggest.

myDetachedDataset.findOrCreate(...); // this can happen without any session

Session ses = SSession.open(datasource);
ses.begin();
ses.attachDataSet(ds);
List<Record> res = ses.findOrcreate(...);
ses.flush();
SDataSet newDs = ses.detachDataSet();
ses.commit();
ses.close();
...

To do this SRecordFinder and SSession should be merged, and it is
SSession that should implement SDataSet.

If the ses.flush() is not done, I suppose newDs would just end up
with dirty records, and the implicit flush in the ses.commit() would
have nothing to do as the records would already have been moved.


I would still like to keep the option of a thread local. Perhaps
using the following style. It is probably SDataSets that can be
optionally connected to the thread locals rather than Sessions.

Session ses2 = SSession.open(datasource);

ses2.setThreadLocal(); // error if there is already a thread local dataset
...
Session ses3=SDataSet.getThreadLocal();
ses3.findOrCreate(...)
...
ses3.close(); // and remove from thread local

(or ses3.clearThreadLocal() to just disconnect without closing
everything. This is in SDataSet, close is in SSession.)


I would also like to add some thread traps. Eg.
volatile private trap=false
doFindOrCreate {
if ( trap ) throw threading error
trap = true
....
finally trap = false
}

It feels like we are getting to the end of the big changes. I
certainly hope so.

Anthony



At 10:35 PM 3/07/2008, Franck Routier wrote:

>Anthony,
>
>I was wondering, why must have so many static methods in SSession, that
>most of the time end up finding the current scon in threadlocal, instead
>of returning a SSession instance on open(), and passing around the
>pointer as needed ?
>
>(I must admit I am not that comfortable with multi-threading issues, so
>what I am saying might be stupid)
>
>Wouldn't:
>
>SSession ses = SSession.open(datasource);
>
>ses.begin();
>ses.attachDataSet(ds);
>List<Record> res = ses.findOrcreate(...);
>ses.flush();
>SDataSet newDs = ses.detachDataSet();
>ses.commit();
>
>SSession.closeSession();
>
>be better ? So the factory+threadLocal part of SSession would be clearly
>identified (public static methods open() and closeSession()), every
>other public method beeing instance methods. This would avoid having to
>get the current session from threadLocal every now and then in the code,
>and would make clear SSession really has two distinct purposes.
>
>As I already said, I am not sure at all about what I'm stating, so your
>opinion on this really matters :)
>
>Franck
>

Dr Anthony Berglas, anthony@... Mobile: +61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose
does not necessarily mean that is the best way to collect firewood.