>>3. We need a lot of control over how data is returned for performance
>>reasons. Two big limitations we are experiencing with Town (that I
believe
>>we would have with Turbine and other abstraction layers) is the inability
to
>>return parts of a ResultSet and to get streamed access to binary data. I
>>believe both of these are critical to increasing scalability and
>>performance.
>I'm still not 100% clear on how the locking of records works (it almost
>sounds like it uses Java's thread locking mechanisms rather than locking by
>setting a flag in the DB). However, If the engine has to periodically
>re-read all the messages in the spool just to send some of them out, then
>I'm all for anything that will turn that around. It just won't scale
>without doing something about this. If someone could explain again how
>this works, I'd appreciate it.
I've been seeing this thread go by and it gave me an idea which I would like
the
members of the group to comment on...
- I think we all would agree that putting a flag
in the Db when a message is busy would greatly improve performance. The
problem
comes when James goes down messages will sit on the spool for ever.
For a solution: what if James generated a unique ID at start up (let's say
long id = (long) ((System.currentTimeMillis()<<8) + Math.random()*x0FF) )
now
our flag table would be of type number and contain the id if the message is
locked. When we set a message to locked all we do is set the column to our
id,
When it's not locked anymore we reset it. In our select we just do something
like select message from message_table where locked flag <> getJamesID()
This way if James crashes it will ignore all the previous locks...
Any thoughts
Ozzy
http://www.unwiredsolutions.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
