> >>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.
I guess I didn't understand that either. It could be as simple as James
checking for locked records when it first comes up and unlocking them.
>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...
Of course, this is a much better solution! :)
>Any thoughts
Good idea!
It almost seems like others are saying this type of thing won't work due to
the way James currently works without locking in the DB. That's why I
wanted a better description of how it works now.
David
>Ozzy
>http://www.unwiredsolutions.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
