With respect to Configuration, all gets go through: private synchronized Properties getProps()
all sets go through: private synchronized Properties getOverlay() private synchronized Properties getProps() and all addResource calls go through: private synchronized void addResource(ArrayList<Object> resources, Object resource) So I think Configuration is thread safe. I think that sharing scanners across threads is probably not a good idea in the first place, but you are correct that the cache is not synchronized. --- Jim Kellerman, Powerset (Live Search, Microsoft Corporation) > -----Original Message----- > From: Andrew Purtell [mailto:[EMAIL PROTECTED] > Sent: Monday, October 13, 2008 11:14 AM > To: [email protected] > Subject: RE: Questions on client API > > Configuration uses unsynchronized lists and hash set. On the other hand if > it is used in a read-only manner after initialization that would be ok. > > I don't think sharing a scanner across threads would be ok because of the > cache of RowResults as an unsynchronized linked list. Otherwise HTable > looks ok to me. > > Am I being overly conservative? > > --- On Mon, 10/13/08, Jim Kellerman (POWERSET) > <[EMAIL PROTECTED]> wrote: > > > From: Jim Kellerman (POWERSET) <[EMAIL PROTECTED]> > > Subject: RE: Questions on client API > > To: "[email protected]" <[email protected]> > > Date: Monday, October 13, 2008, 10:48 AM > > Andrew, > > > > What methods in HBaseConfiguration and HTable do you think > > are not re-entrant? > > > > --- > > Jim Kellerman, Powerset (Live Search, Microsoft > > Corporation) > > > > > > > -----Original Message----- > > > From: Michael Dagaev [mailto:[EMAIL PROTECTED] > > > Sent: Monday, October 13, 2008 10:24 AM > > > To: [email protected]; [EMAIL PROTECTED] > > > Subject: Re: Questions on client API > > > > > > Hi Andrew > > > > > > Hmmm ...I would not like to instantiate > > HBaseConfiguration per > > > thread. I would prefer to create it once per > > application so many > > > threads will use it concurrently. > > > > > > Thank you for pointing out this issue. I will check > > the code. > > > M. > > > > > > On Mon, Oct 13, 2008 at 6:54 PM, Andrew Purtell > > <[EMAIL PROTECTED]> > > > wrote: > > > > Hello Michael, > > > > > > > > Your understanding regarding connection pooling > > is correct. > > > > > > > > Looking at the code, I see that some methods of > > > > HBaseConfiguration and HTable are not fully > > reentrant, so I > > > > would not share them across multiple threads, or > > at least I > > > > would explicitly synchronize access to them. > > > > > > > > - Andy > > > > > > > > > > > >> From: Michael Dagaev > > <[EMAIL PROTECTED]> > > > >> Subject: Questions on client API > > > >> To: [email protected] > > > >> Date: Monday, October 13, 2008, 2:54 AM > > > >> Hi All > > > >> > > > >> As I understand, the HTable class uses > > > >> HConnectionManager class, which holds > > connections to the > > > >> master and region servers. The connections > > are pooled as > > > >> entries in a thread-safe static table (map). > > Thus, a > > > >> client application should not care about > > connection > > > >> pooling. Is it correct? > > > >> > > > >> May several threads share the same > > instance of > > > >> HbaseConfiguration ? HTable? > > > >> > > > >> Thank you for your cooperation, > > > >> M. > > > > > > > > > > > > > > > > > > > > > > >
