[JBoss JIRA] Commented: (JBRULES-261) Mismatched types in field constraints
by Michael Neale (JIRA)
[ http://jira.jboss.com/jira/browse/JBRULES-261?page=comments#action_12352810 ]
Michael Neale commented on JBRULES-261:
---------------------------------------
defaintely automatic. We don't want to be as rigid with types as java is.
Of course, if there is any "loss" of data resolution, that is a problem, but if there is not, then automatic is good.
> Mismatched types in field constraints
> -------------------------------------
>
> Key: JBRULES-261
> URL: http://jira.jboss.com/jira/browse/JBRULES-261
> Project: JBoss Rules
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Rule Assemply/SPI
> Affects Versions: 3.0.1
> Reporter: Michael Neale
> Assigned To: Mark Proctor
> Priority: Minor
> Fix For: 3.1-m2
>
>
> Problem: If a rule compares two fields and one of them is a char and the
> other one is a String, the match is always negative. No type-mismatch error
> or warning is displayed. This can be quite confusing. The attached Eclipse
> project illustrates this problem.
> Suggested Solution: If all information is available at compile-time an error
> should be generated on type mismatches. Otherwise there should be a warning
> during run-time and maybe a type conversion attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBCACHE-955) Restore ability to insert and remove child nodes with only a read lock on the parent
by Brian Stansberry (JIRA)
Restore ability to insert and remove child nodes with only a read lock on the parent
------------------------------------------------------------------------------------
Key: JBCACHE-955
URL: http://jira.jboss.com/jira/browse/JBCACHE-955
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Critical
Fix For: 2.0.0.BETA1, 1.4.1.SP1
In 1.4.1.GA JBC introduced tighter locking semantics wherein the insertion or removal of a node required a write lock on the parent. In recent previous versions (and maybe always) only a read lock was required.
The 1.4.1.GA behavior provides greater correctness, but at a cost of lesser concurrency. Some applications written assuming the old behavior will not function properly with the new behavior.
Speaking in db isolation terms, let's say a non-repeatable-read means a tx reads a node's *data map* twice and gets different results. A phantom read means a tx reads a node's *child map* twice and gets different results. Conceptually, a JBC node represents both a "row" (data map) and a query result set (children map -- set of rows that share a common characteristic that the parent represents). (I know this analogy is inexact, but, ...).
In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get non-repeatable-reads, but could get phantom reads. With 1.4.1, you also don't get phantom reads (at least with respect to a node's immediate children). But, in many cases this behavior is unneeded and undesirable, and JBC no longer offers the old behavior.
This JIRA will restore the old behavior for the pessimistic locking use case. A new cache configuration flag LockParentForChildInsertRemove will be added. If set to false, the 1.4.0.SP1 behavior of only requiring the RL will be restored. The default value of the flag will be true.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-825) Transactions corrupted because sybase truncates trailing zeros
by Tim Fox (JIRA)
Transactions corrupted because sybase truncates trailing zeros
--------------------------------------------------------------
Key: JBMESSAGING-825
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-825
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.2.0.Beta2
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.2.0.CR1
Sybase has the wonderful characteristic of truncating trailing zeros in VARBINARY columns.
So If I set a byte array with values: 1, 2, 3, 4, 5, 0, 0, 0
Then I get back a byte array with values: 1, 2, 3, 4, 5
Xid global txids and branch qualifiers can have trailing zeros since they can become corrupt after storing and retrieving in the database.
Solution is to introduce a flag "usingTrailingByte" on the pm config. If true then a non zero byte will always be appended to the byte[] before storing and removed on retrieval.
This flag should be true for sybase config and false for others.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months