0

I have a few camel routes that call an external web service, i need to manage a session pool for this web service, keeping a few sessions open and reusing idle ones each time a camel route needs one.

Which is "safer" : - managing/persisting the session data in a db using JDBC for example or - implementing a static or singleton pool using apache-commons pool for example

redben
  • 5,578
  • 5
  • 47
  • 63
  • What do you really refer to for "web service session"? As you use CXF I suppose you use JAX-WS/JAXB. That means you need to take care of JAX-WS client proxies and share them where possible. You can't pool session, because for SOAP and REST WebServices it does not exist. – dma_k Feb 01 '12 at 22:18
  • the wsdl has two operations signin (returns a session number) and signout. I need to keep a set of "sessions" pooled so as to limit calls to signin/signout – redben Feb 02 '12 at 18:27
  • Your session in WebService is represented by some SessionID, which you need to save/pool. I don't know any other means how WebService can identify the client. So you basically need to pool WebService response (or part of it) to login operation. This response may leave in pool no longer then session timeout on WebService side. – dma_k Feb 02 '12 at 23:19
  • Exactly now you got it :) so back to my question : is managing this pool on a db table better or is an in memory pool (using commons pool for example) better – redben Feb 03 '12 at 10:56
  • If your WebService session is valid for days and you want to recover your opened sessions after e.g. crash on client side, or you want to share opened sessions among several clients via DB, then I would use DB. Otherwise if you have only one client, or it is OK that each client has it's own small cache, I would use in-memory pool. – dma_k Feb 04 '12 at 11:47
  • Thanks ! could you put it as a sof answer ? – redben Feb 04 '12 at 13:06

2 Answers2

1

Your session in WebService is represented by some SessionID, which you need to save/pool.So you basically need to pool WebService response (or part of it) which is returned by login operation. This response may leave in pool no longer then session timeout on WebService side.

If your WebService session is valid for days on server side and you want to recover your opened sessions after e.g. crash on client side, or you want to share opened sessions among several clients via DB, then I would use DB.

Otherwise if you have only one client, or it is OK that each client has it's own small cache, I would use in-memory pool. As subalternative you may think about sharing this pool among clients / multiple applications by means of Ehcache/Terracotta. And, by the way, these caches allow you to dump the pool contents contents to disk, which might be a good alternative to DB out-of-the-box.

dma_k
  • 10,431
  • 16
  • 76
  • 128
0

if you are talking about JDBC connection pooling, then I'd recommend using DBCP or C3P0. If you are talking about POJO object pooling, then look at Spring object pooling

Ben ODay
  • 20,784
  • 9
  • 45
  • 68
  • In fact i need to keep some remote web services sessions open so as not to keep opening and closing sessions for each operation call. I first thought I'd persist session objects in a db (using JDBC) then I decided to use an apache-commons pool (as a static property in a bean) , the pool's object factory handles calling open and close methods (makeObject/destroyObject) on the remote web service. Do you think it is ok to use this (static) approach ? – redben Jan 27 '12 at 10:38