- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Spin-off: RdB problem
Operating System - OpenVMS
1748181
Members
3637
Online
108759
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 06:06 AM
тАО02-06-2008 06:06 AM
This thread http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1200857 offers another functional problem. I didn't want to hijack the thread since that is another matter.
-----
Waiting: 202054F6 _TNA282:....... 5E00A732 00010001 EX
Blocker: 202054F5 _TNA281:....... 550021A6 00010001 PR
-----
My assumption is that if process PID 202054F6 tries to delete a record that has been fetched before by process PID 202054F5.
This seems rather obvious to me.
But what would happen if a third process comes along and would access the same record? It would depend on the transaction setting, propably, but this would be my estimate:
Read only, reserving this table for shared read: SUCCESS
Read only, reserving this table for shared write: SUCCESS
Read write, reserving this table for shared read: SUCCESS
Read write, reserving this table for shared write: WAIT (or FAIL)
and as long as there is a process accessing the record, theprocess trying to delete the record will wait until all processes would commit or rollback their transactions.
It the assumption correct, of what have I misunderstood?
-----
Waiting: 202054F6 _TNA282:....... 5E00A732 00010001 EX
Blocker: 202054F5 _TNA281:....... 550021A6 00010001 PR
-----
My assumption is that if process PID 202054F6 tries to delete a record that has been fetched before by process PID 202054F5.
This seems rather obvious to me.
But what would happen if a third process comes along and would access the same record? It would depend on the transaction setting, propably, but this would be my estimate:
Read only, reserving this table for shared read: SUCCESS
Read only, reserving this table for shared write: SUCCESS
Read write, reserving this table for shared read: SUCCESS
Read write, reserving this table for shared write: WAIT (or FAIL)
and as long as there is a process accessing the record, theprocess trying to delete the record will wait until all processes would commit or rollback their transactions.
It the assumption correct, of what have I misunderstood?
Willem Grooters
OpenVMS Developer & System Manager
OpenVMS Developer & System Manager
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 08:12 AM
тАО02-06-2008 08:12 AM
Solution
A read only can't reserve a table for shared write - write access is not compatible with read only -
Any other read write transaction will wait because on the record already exists a waiting transaction.
It the 3rd transaction was allowed to read the record (setting a PR lock which is compatible with the current granted lock PR) this can lead to a famine where a transaction will never succeeded to update a record.
Any other read write transaction will wait because on the record already exists a waiting transaction.
It the 3rd transaction was allowed to read the record (setting a PR lock which is compatible with the current granted lock PR) this can lead to a famine where a transaction will never succeeded to update a record.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 06:47 AM
тАО02-25-2008 06:47 AM
Re: Spin-off: RdB problem
Oops - misfit in perception on my side: It's the requestor's intent that counts, not what the rest of the world could do. Makes sense with EX...
If I undertsood the Black Book correctly, it would mean a PW lock will indeed wait - because incomptability with PR, and not because of EX. But since EX is queued before, it will be granted first. Same result, though. And yes: if another PR comes along, and another, and another, the process requesting EX will have a problem.
WG
If I undertsood the Black Book correctly, it would mean a PW lock will indeed wait - because incomptability with PR, and not because of EX. But since EX is queued before, it will be granted first. Same result, though. And yes: if another PR comes along, and another, and another, the process requesting EX will have a problem.
WG
Willem Grooters
OpenVMS Developer & System Manager
OpenVMS Developer & System Manager
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP