Hello gregor,
thank you for your comments.
I implemented an DB Connection Manager class, based on apache commons
dbcp, which holds a connection pool with an prepared statement cache.
Now the DB access method in my Handler allocates an exclusive connection
from this pool.
With this I could get rid of all synchronization. This pushed the
performance from ~ 300 ms per message (with sync) to ~ 50-100 ms per
message.
Fair enough in my opinion.
xSocket convinced me, again I have to state great work.
Sven
Gregor Roth schrieb:
>
> Hi Sven,
>
>
> please see my comments
>
>
> gregor
>
>
>
>> ----- Original Message -----
>>
>> From: Sven Eisenhauer
>>
>> Sent: 05/03/09 10:23 am
>>
>> To: xso...@li...
>>
>> Subject: [xSocket-develop] Question about xSocket
>>
>>
>>
>> Hello *,
>> I am new to xSocket, but up to now I am very happy with it, great work.
>> I have implement my first server using non-blocking connections for a
>> custom protocol based on tcp.
>> Everything works fine up to now.
>>
>> But I have one question open, perhaps somebody here on the list could
>> clarify this:
>> I have written a Handler for my protocol, which I pass to the server
>> according to the tutorial:
>>
>> IServer srv = new Server(PORT,new MyHandler());
>>
>> Am I right that there only exists one instance of a MyHandler object and
>>
>> there are new Handler-Threads created always using this object?
>>
>>
>> >> Yes, this is true.
>>
>>
>>
>> MyHandler receives one message per minute on every non-blocking
>> connection. This message is converted and must be inserted in a database
>> table.
>> For this MyHandler has a jdbc database connection object with several
>> prepared statements as an attribute.
>> During my tests I have observed, that there occur database exceptions. I
>> assumed that different Handler-Threads operate on the same prepared
>> statement so that it becomes corrupted. After putting the hole database
>> access in a synchronized method of MyHandler this phenomenon disappeared.
>>
>> Now my question:
>> Am I right, that in this situation only one Handler thread can access
>>
>> the database at one time and all others are blocked?
>>
>>
>> >> Yes, if you synchronize the onRequestMethod all conncurrent
>> requests will be blocked. As already mentioned, only one instance of
>> the Handler exists
>>
>>
>> If this is right, I assume that the database access could become a
>> bottleneck. There is only one database connection for all
>> Handler-Threads.
>> How could I open this bottleneck?
>> One alternative I thought off is that I open up a database connection
>> for every non-blocking connection to a client and attach it to the
>> non-blocking connection. But this seems a little bit as an overkill to
>> open up 1000 database connections for 1000 client connections and every
>>
>> connection is used only once per minute.
>>
>>
>> In my opinion it would be much better to have a database connection for
>>
>> every Handler-Thread. What's your opinion about this?
>>
>>
>> And how could I implement it? Setting up a database connection pool with
>> apache-commons dbcp or something else should be no rocket science.
>> But how to implement a Handler, that always asks for a db-connection
>> from the pool? And would I have to prepare the statements every time a
>>
>> Handler runs?
>>
>>
>> >> I would recomend this solution. I my option the handler
>> implementation could hold the pool.
>>
>>
>>
>>
>> Best regards and thanks in advance,
>> Sven
>>
>> --
>> Sven Eisenhauer, B.Sc.
>> SYNERVA GmbH
>> Mergenthalerallee 55
>> 65760 Eschborn
>> Deutschland
>> Fon: +49 [069] 33 99 66 99
>> Fax: +49 [069] 33 99 66 98
>> mailto:eis...@sy...
>> http://www.synerva.de
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> xSocket-develop mailing list
>> xSo...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsocket-develop
>
>
>
>
--
Sven Eisenhauer, B.Sc.
SYNERVA GmbH
Mergenthalerallee 55
65760 Eschborn
Deutschland
Fon: +49 [069] 33 99 66 99
Fax: +49 [069] 33 99 66 98
mailto:eis...@sy...
http://www.synerva.de
|
