Re: [firebird-support] Is it save to append some data at end of the binary firebird database file?
[firebird-support] Re: Is it save to append some data at end of the binary firebird database file?
Thank you. Seems to be a nice idea, but how to implement it? Is there an easy way to handle this with a linux install scipt or install shield on windows? If this is not the case I think I will use an exe to get the information out of the database. I will use C++ and IBPP, since this is already working fine for the rest of the project.
[firebird-support] Re: Is it save to append some data at end of the binary firebird database file?
We already had this idea ourselfs (I think it's the easiest way). But the problem is that two files easily can lead to unconsistency. Since editing the binary firebird dataformat seems not to be a good idea we will probably ship a little exe with our installer getting the version out of the database (where it is stored in a special table).
Re: [firebird-support] Deleting records and deadlocks
On Wed, Dec 2, 2015 at 11:49 AM, Tim Ward t...@telensa.com [firebird-support] wrote: > > > Yes I do know it's not a real deadlock, I was using the word because I > knew it would be understood and because, I'm pretty sure?, I've seen it > in one of the relevant error messages. > This is really ancient history, but the reason that update conflicts are reported as deadlocks is rooted in the early dark ages of computing, say around 1981. DEC, to its distress, found itself developing two relational databases, one a relational layer on a CODASYL system, and one relational from the ground up using multi-generational concurrency control (created by Jim Starkey). Management decreed that the two systems be compatible shared libraries. Change a link and your application goes from using one to using the other without changes. That meant compatible everything but ODS - system tables, api, and error codes. The solution for error codes was to agree on major error codes that an application could receive and respond to, with the possibility of minor codes to for system specific behavior. Since the solution to an update conflict (not a possibility in the lock-based traditional implementation) is the same as the resolution of a deadlock - rollback and try again - it was lumped under deadlock. When Jim created InterBase, he used the same interfaces in hopes of gaining market share from VAX/RDBMS users who wanted a compatible interface on other hardware. Alas, by that time anyone still using VAXen was so addicted to DEC that they wouldn't consider other hardware let alone foreign software. Cheers, Ann
Re: [firebird-support] Deleting records and deadlocks
Thanks for the replies. Don't worry folks, I'm not going to try this, I was just curious. Yes I do know it's not a real deadlock, I was using the word because I knew it would be understood and because, I'm pretty sure?, I've seen it in one of the relevant error messages. -- Tim Ward ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Deleting records and deadlocks
Den 02.12.2015 13:24, skrev Ann Harrison aharri...@ibphoenix.com [firebird-support]: >> On Dec 2, 2015, at 6:35 AM, Tim Ward t...@telensa.com [firebird-support] >> wrote: >> >> What about if two concurrent transactions are both trying to *delete* >> the *same* record at once? - from the point of the view of the user's >> objectives there's no reason why this shouldn't work, as either way the >> record is going to end up deleted, which is what the user wants, but >> would I be right in guessing that Firebird isn't that clever, and that >> deadlocks are possible in this scenario? > It's not nearly that simple. What would happen if one of those transactions > rolled back? > > Good luck, > > Ann Logically, I don't see any difference between an update and a delete. If two transactions that had done nothing possibly excepting reading the record simultaneously tried to delete the same record, I would expect one of them to succeed and the other to get a lock conflict (not the same as a deadlock, but many persons, probably including you, use the term deadlock when they mean lock conflict). One way to avoid this particuar kind of lock conflict, would be to not delete the record directly from the clients, but rather insert it into a table that you e.g. could call DELETED. Never let any user directly delete from the DELETED table, but have a housekeeping routine that at regular intervals delete records (from both your main table and the DELETED table). I.e. similar to what is sometimes done with extra tables having COUNTs and inserting new records with +1 or -1 when adding or removing items. Though I must admit I've never heard of anyone using this technique for DELETE. Set ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Deleting records and deadlocks
> On Dec 2, 2015, at 6:35 AM, Tim Ward t...@telensa.com [firebird-support] > wrote: > > What about if two concurrent transactions are both trying to *delete* > the *same* record at once? - from the point of the view of the user's > objectives there's no reason why this shouldn't work, as either way the > record is going to end up deleted, which is what the user wants, but > would I be right in guessing that Firebird isn't that clever, and that > deadlocks are possible in this scenario? It's not nearly that simple. What would happen if one of those transactions rolled back? Good luck, Ann
[firebird-support] Deleting records and deadlocks
I know that if two concurrent transactions try to make changes to the same record at the same time one of them gets a deadlock. What about if two concurrent transactions are both trying to *delete* the *same* record at once? - from the point of the view of the user's objectives there's no reason why this shouldn't work, as either way the record is going to end up deleted, which is what the user wants, but would I be right in guessing that Firebird isn't that clever, and that deadlocks are possible in this scenario? -- Tim Ward
