http://highscalability.com/blog/2011/6/21/running-tpc-c-on-mysqlrds.html
Results Analysis
The benchmark results are surprising.
With hardly any dependency on the database size, MySQL reaches its
optimal throughput at around 64 concurrent users. Anything above that
causes throughput degradation
Jim,
> Would it be possible and desirable to have FreePascal as an embedded
> stored procedure/trigger language in some future release of Firebird?
> (I
> can't recall this having been brought up before, so I just start the
> ball rolling).
I did not check the current state of Java "plugin", but
>> So, considering this all, there should be (theoretically) no problem
>> of
>> compiling the code in Free Pascal as long as it will produce
>> binaries
>> with appropriate entry points. That should be possible
>> out-of-the-box
>> (at least it was discussed that way few years ago).
>
> Is prob
>>> Is problem with exceptions processing in windows and FP is solved?
>>> It
>>> was noticed sometimes that FP UDFs block exception handling in
>>> firebird.
>> No clue, never used FP at all. But I would classify that as a bug
>> which
>> should be eliminated when such integration is implemented
>> 6. Just in time compilation of the embedded procedure on first use
>> (after create/alter) into a shared library/DLL which is then
>> effectively
>> a dynamically generated UDF library. A JIT approach is important
>> because
>> the database can be moved between processor architectures/platform
> And the Java plugin security works like a Java applet running in your
> browser.
>
> It's by default configured to allows nothing that can danger the
> machine.
>
> But say you need to access the network, you put a record in the java
> security database saying the user or role has the permission
>> Oh, so you have implemented a proper security manager for the Java
>> ESPs? You are great man! :)
>
> It was difficult and initially was failing only in Linux. But after
> changes it worked ok as far as I can test.
Will it accept also a default security manager with java.policy file?
So that a
>> And this not protect you from Java Trojan downloader for example.
> What do you mean?
If I remember correctly, that was a JAR with "manipulated" byte-code
which exploited some particular JVMs when the code was executed (at
least it was able to download malware from the network and execute the
> Look at isc_prepare_transaction2() API. It could attach *any*
> application-specific
> message to the local transaction before actual commit. TM could pass XID +
> "something
> to identify this part of distributed transaction" into
> isc_prepare_transaction and later read
> this info bac
>
> I can't understand the objection. The only think that I do see here
> are objections without explaining why. Why such type of features will
> be bad ?
> Why time based data manipulation are not good for databases but should
> be external ?
> Don't get me wrong, if I'll understand why, I will wr
.
Roman Rokytskyy
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include end
> Without default client charset too, this is a partial solution. Not all
> applications are written in Java and .NET.
Sure, but defaulting should not happen in fbclient.dll, but in the FB
access library, IBPP for C++, UIB or whatever components are currently
used in Delphi. AFAIK, Delphi is Uni
>> The only change is that newly created databases are created with some
>> meaningful charset, not with "raw data". The rest remains as it is now -
>> those that want to manage it already, will be able to do this.
>
> In this case why to configure the default? Let's hardcode it to UTF-8!
Yes,
> Why not make the DEFAULT CHARACTER SET clause required? So everybody
> who creates a database *must* define one and make sure it's the right
> one.
Yes, this is also an option. Maybe even the easiest one.
Roman
--
Liv
Am 15. Juli 2012 18:23:55 schrieb Mark Rotteveel
>
> I do know that Roman was already planning to migrate to Subversion
> before I joined, so maybe he has additional reasons.
Reasons were:
- same VCS for Firebird (core project uses SVN, some others do as well);
- should be supported by SF.net an
> Actually, server makes a lot more sense than client, eg the embedded
> engine for clientside datastorage. IMHO you shouldn't connect directly
> from a mobile phone to an external databaseserver, it is inefficient and
> a lot harder to secure than for example a specific webservice.
I agree with M
16 matches
Mail list logo
