>> -Original Message-
>> From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
>> Sent: Lunes, 09 de Mayo de 2011 6:07
>
>> To avoid contention on common dbb_pool its usage was
>> replaced by att_pool when
>> possible. To make this task slightly easy there was
>> introduced j
> -Original Message-
> From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
> Sent: Lunes, 09 de Mayo de 2011 6:07
> To avoid contention on common dbb_pool its usage was
> replaced by att_pool when
> possible. To make this task slightly easy there was
> introduced jrd_rel::r
On 05/10/11 11:40, Vlad Khorsun wrote:
>> Do we really need the SharedCache option in production?
> It was implicitly introduced by Alex and i just add it to the config
> file. I see no problem
> if we remove it - less options is less headache for us and for users :)
>
That means that we dr
On 05/09/11 14:06, Vlad Khorsun wrote:
> To run SuperClassic you should use switch -m in command line of
> firebird.exe
> (on Windows) or run fb_smp_server (on Posix, here i'm not sure and Alex will
> correct me)
Small correction. There is no more fb_smp_server on posix. There is also
single
On 05/09/11 21:15, Dimitry Sibiryakov wrote:
> 09.05.2011 18:48, Leyne, Sean wrote:
>>> I disagree. Shadow is the only method for synchronous replication in
>>> Firebird now.
>> Synchronous replication on a single server is not replication.
>Don't forget about NFS and iSCSI(?).
Why _only_
>>> Are there any database-level ASTs known to implicitly access the
>>> attachments? When should they lock the appropriate mutex?
>>
>> Database-level ASTs not need to access attachment internals usually.
>
> "Usually" differs from "always" :-) I seem to remember cases when the
> AST saves lck_a
10.05.2011 10:11, Vlad Khorsun wrote:
>>In this case may I suggest to use separate memory pool for the cache's
>> elements?..
>
> It is already separate
>
>> Someday someone could implement shared memory pool...
>
> It is already shared ;)
Shared between processes, I mean.
--
10.05.2011 11:40, Vlad Khorsun wrote:
>> Are there any database-level ASTs known to implicitly access the
>> attachments? When should they lock the appropriate mutex?
>
> Database-level ASTs not need to access attachment internals usually.
"Usually" differs from "always" :-) I seem to remember ca
> In this case may I suggest to use separate memory pool for the cache's
> elements?..
It is already separate
> Someday someone could implement shared memory pool...
It is already shared ;)
Regards,
Vlad
--
10.05.2011 9:53, Vlad Khorsun wrote:
As long as it
keeps launching one process per connection, there's no difference
between SharedCache being true or false, as there will always be only
one Database/Attachment pair per process.
>>>
>>> Sure
>>
>>Isn't the cache shared
10.05.2011 11:46, Dimitry Sibiryakov wrote:
> Isn't the cache shared between processes?
In your dreams, perhaps. There was never such a goal.
Dmitry
--
Achieve unprecedented app performance and reliability
What every C
>>> As long as it
>>> keeps launching one process per connection, there's no difference
>>> between SharedCache being true or false, as there will always be only
>>> one Database/Attachment pair per process.
>>
>> Sure
>
> Isn't the cache shared between processes?
No. There was never s
10.05.2011 9:40, Vlad Khorsun wrote:
>> As long as it
>> keeps launching one process per connection, there's no difference
>> between SharedCache being true or false, as there will always be only
>> one Database/Attachment pair per process.
>
> Sure
Isn't the cache shared between processes
>> All metadata objects moved into Attachment. Metadata syncronization is
>> guarded
>> by attachment's mutex now. Database::SyncGuard and company are replaced by
>> corresponding Attachment::XXX classes.
>>
>> To make AST's work we need to release attachment mutex sometimes. This is
>> very
>> i
09.05.2011 14:06, Vlad Khorsun wrote:
>
> All metadata objects moved into Attachment. Metadata syncronization is guarded
> by attachment's mutex now. Database::SyncGuard and company are replaced by
> corresponding Attachment::XXX classes.
>
> To make AST's work we need to release attachment mutex s
> >Further, I do see your firm ponying up to sponsor the testing effort (thru
> the Firebird Foundation) required to test new features in arcane usage
> modes.
>
> ...do NOT see? ...
Correct, ... do not see
Typo, grr
Sean
---
At 07:29 AM 10/05/2011, Leyne, Sean wrote:
>> > So, again, do not make assumptions about the viability of a feature
>> > when you are not familiar with how it is used in the field.
>>
>> What about your assumption that Firebird should worry about your
>> outdated/custom/unique OSs for every new r
> > So, again, do not make assumptions about the viability of a feature
> > when you are not familiar with how it is used in the field.
>
> What about your assumption that Firebird should worry about your
> outdated/custom/unique OSs for every new release?
Further, I do see your firm ponying up
> The Mac and Linux support of NTFS are not certified and cannot be given the
> license model, so you depend upon add on drivers which do not meet the
> requirements for internal use - also, NTFS is not reliable under load, even on
> a server 2008 box.
I thought we were talking about transferrin
I will not discuss if the shadow is (still) a valid concept or not
(regarding safety), but since FB doesn't offer native replication,
cluster, etc, shadow is the only "anti-failure" thing that we can say
Firebird offers natively (even when we know that the "safety" level is
very limited).
So, even
Sean, we have operating systems in use that predate NTFS. We have
custom hardware that operates on custom OS's where the CPU's are based
upon fpga (field programmable gate arrays) which are the gateway
systems onto the SS7 network which happen to hold firebird databases
which handle over 2 milli
> > 1 - you are still using a Win98 system and so NTFS isn't supported???
>
> NTFS is not supported on some forms of solaris, linux and other OS's we have
> in the office - windows is not the only operating system on the market and
> many standalone devices only support the win98/fat32 formats d
> 1 - you are still using a Win98 system and so NTFS isn't supported???
NTFS is not supported on some forms of solaris, linux and other OS's
we have in the office - windows is not the only operating system on
the market and many standalone devices only support the win98/fat32
formats due to MS lic
> 09.05.2011 18:48, Leyne, Sean wrote:
> >> I disagree. Shadow is the only method for synchronous replication
> >> in Firebird now.
> >
> > Synchronous replication on a single server is not replication.
>
>Don't forget about NFS and iSCSI(?).
Shadow was designed as an early software RAID
On 09/05/2011 14:41, Leyne, Sean wrote:
>
> Just like changes have been made to the SQL syntax that FB supports, changes
> to the file configurations which are supported must evolve...
>
This depends. It's almost always true for horrible implementations
inherited from Interbase.
But if a feature
Dalton,
> Being able to spread a database across multiple files is a great feature when
> moving large databases on devices that do not support large file support -
> such as 32GB thumb drives that still use a form of FAT32 for their file
> system.
I'm sorry but ...
1 - you are still using a W
09.05.2011 18:48, Leyne, Sean wrote:
>> I disagree. Shadow is the only method for synchronous replication in
>> Firebird now.
>
> Synchronous replication on a single server is not replication.
Don't forget about NFS and iSCSI(?).
--
SY, SD.
Being able to spread a database across multiple files is a great
feature when moving large databases on devices that do not support
large file support - such as 32GB thumb drives that still use a form
of FAT32 for their file system.Sure we can format them up with a
different filing system but t
>I disagree. Shadow is the only method for synchronous replication in
> Firebird now.
Synchronous replication on a single server is not replication.
Sean
--
WhatsUp Gold - Download Free Network Management Softwar
09.05.2011 18:27, Leyne, Sean wrote:
>> - shadow - not tested
>
> I would like to propose that support for database Shadow be completely
> dropped in v3
I disagree. Shadow is the only method for synchronous replication in
Firebird now.
Before of dropping it, a replacement should be proposed.
Vlad,
> After more than a year of development, testing, switching on another
> tasks and returning back i'm ready to commit shared page cache
> implementation into trunk.
Great news!
> ...
> About stability testing of different parts of the engine :
>...
> - shadow - not tested
I would
Hi all.
After more than a year of development, testing, switching on another tasks
and
returning back i'm ready to commit shared page cache implementation into trunk.
I consider it stable enough to be committed into SVN. It runs some
stability tests
more than 10 hours for longest r
32 matches
Mail list logo
