Yusuf

I can reproduce this! Yes you're right, the configurations seems to be locked as long the Query is running. After some timeout, the 506 Error is comming.

So it looks there is a problem with the configuration in this case. Bufferd I/O or not makes no difference, as I don't use Buffered I/O and see this behaviour too.

Now the questionis: Is this as designed be Tim? Tim any infos on this?

Yusuf

That is excellent. You now have something concrete and reproducible for Tim to look at.

Roy

On 4/30/2019 9:40 AM, Roy Lambert wrote:
> If the CPU is only hitting 25% that suggests there's plenty of spare capacity even running your million row result set query. That in turn suggests that its something in your server modifications. Have you tried the same experiment with a standard server?

in today's multi-core world this likely means 1 CPU core is maxing out
100% so there might be capacity left but only for other sessions (on new
threads or processed)

Raul

On 4/30/2019 10:22 AM, Yusuf Zorlu wrote:
> I have started the demo-server from Rio-Installation: \servers\edbsrvr\win64
> 1. created two tables and inserted a lot of data
> 2. run select * from table1, table2
> 3. open a new edbmanager
> 4. connect to session and click to "manage server sessions"
> 5. ElevateDB Error #506 Cannot lock the session manager (ID: 3)
>
> I have used default configuration of server with buffering DISABLED and default configuration.

I suggest you email this to elevate support - Tim does read these
newsgroups but for quicker response support email is better.

I personally suspect issue is with (read) locks - i don't know EDB
internal enough though so this is total wild guess

Raul

Raul

>in today's multi-core world this likely means 1 CPU core is maxing out
>100% so there might be capacity left but only for other sessions (on new
>threads or processed)

Good point. I do wish the term session wasn't so used for different things so I could really understand which flavour session was being referred to at the time. Its not always obvius from contect

Roy

Ok guys, it seems that the blocking of configuration tables is the main problem, let me describe what we do:

1. a lot of concurrent users are working within our client
2. all use pesimistic locking with remote sessions
3. one user edit's a datarow
4. second and/or third user tries to edit same row

and so it starts as follows ...

5. second and/or third user gets a EDB_ERROR_LOCKROW (1005)
6. so we want to show the users who is locking the record with this:

SELECT SSL.*, SS.* FROM Configuration.ServerSessionLocks SSL
LEFT JOIN Configuration.ServerSessions SS ON (SS.ID = SSL.SessionID)
WHERE LockType='Row' AND ObjectType='Table' AND ObjectName='%TABLENAME%'

7. but meanwhile / at the same time some other sessions doing long queries .... blocking configuration.serversessionlocks ...
8. second and/or third user now gets a "#506 Cannot lock the session manager" after timeout

9. but we are since 4. in a try - except block, 6 is called within the except block to get the locking users details and has again a try - except block which catches the #506 but in our case has a bug and don't raises this second exception #506

Wow. Hope this helps Tim to understand things. It seems that we are searching now for months for a bug which slows down our app with a lot of hangers and it seems that the described here is the complete problem.

We will try to show the second exceptions to the user! But now we must know if it is normal that the configuration.* tables are locked as described or not. if so we need to create something different to know which user is the current "Locker" of the dataset-row ... As i remember, Tim has planned something here with the new Buffered I/O.

Tim can you enlight us a little bit? Can you reproduce the described procedure on page 2 on your side to get the configuration.* locked?

Thanks for some feedback.

Yusuf Zorlu
MicrotronX

On 5/1/2019 2:43 AM, Roy Lambert wrote:
> Good point. I do wish the term session wasn't so used for different things so I could really understand which flavour session was being referred to at the time. Its not always obvius from contect

In this case i meant session on the EDBRVR which runs on its own thread
(and i believe also corresponds to server side of the a remote client
session )

Raul

Yusuf,

<< I wanted to know if other users / developers have same things. >>

That's fine, but that's not what you posted.  You specifically went out of your way to post about something that you *know* that I have tried to reproduce for weeks upon weeks, and have been unsuccessful in doing so.  In other words, I have zero evidence at this point that what you are seeing is even true (client corrupts data on the server).  The closest that I came to producing something that approximates this was by manually modifying the row ID in the buffer that was sent over to the EDB Server from the client, and even that didn't really reproduce what you were seeing, it just simply caused another issue (possible AV, but not corruption).  And, this particular vulnerability was corrected in 2.30 (it might have been 2.31).

Tim Young
Elevate Software
www.elevatesoft.com

Ok Tim it is possible that I have overreacted ... But we are not kids playing at the playground.

We switched to ElevateDb and we have problems ... And yes we thank you for all of your work and support for helping us to solve them but we still have problems...

Don't forget we have over 260 customers with a total of more than 1400 users and that means we have big trouble if our product hangs or makes problems ... Having calls all the day because of this I am overstressed and possible I overreacted but pls understand my position!

Can you say something about locked configuration.serversessions in case / example on page 2 of this thread?
Yusuf Zorlu
MicrotronX

Yusuf Zorlu

<<
a lot of concurrent users are working within our client
2. all use pesimistic locking with remote sessions
3. one user edit's a datarow
4. second and/or third user tries to edit same row
>>

According my experience with a lot of concurrent users my suggestion is to change the pessimistic locking model to optimistic. A lot of troubles you are seeing will dissapear and let the control of things to database (DBISAM and ElevateDB). There will be just a little lock while your application is postiing the record. In the model you are using if the user press "Edit" button and go to the bathroom, go to drink a coffee or anything else the record will be locked until the application is active then stopping *ALL* of other users.

Well, this is just my tip. I never need to know where user is locking a particular table because the concurrency situation (with optimistic model) is very rare.

Regards

Eduardo